Dokumente hinzugefügt

docs/specs/fachliche-anforderungen.md

@@ -0,0 +1,779 @@
+# 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.

docs/specs/meilensteine.md

@@ -0,0 +1,507 @@
+# Meilensteine
+
+> **Dokumentversion:** v3
+> **Stand:** 08.04.2026
+> **Status:** verbindliche Meilensteinstruktur für die Implementierung von Version 1
+> **Projekt:** ASV-Format-Validator
+> **Primärquelle:** `Spec.docx` – Technische Anlage ASV 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026
+> **Begleitdokumente:** `fachliche-anforderungen.md` v4, `technik-und-architektur.md` v5
+
+## 1. Zweck dieses Dokuments
+
+Dieses Dokument untergliedert die Implementierung des Projekts **ASV-Format-Validator** in fachlich und technisch sinnvolle **Meilensteine** für Version 1.
+
+**Rangfolge der Dokumente:**
+
+1. `Spec.docx` ist die normative fachlich-technische Wahrheit. Bei jeder Kollision gilt die Spezifikation.
+2. `fachliche-anforderungen.md` v4 ist der verbindliche fachliche Soll-Rahmen.
+3. `technik-und-architektur.md` v5 ist der verbindliche technische Soll-Rahmen.
+4. Dieses Dokument **strukturiert lediglich die Umsetzung** der oben genannten Grunddokumente in eine sinnvolle Reihenfolge. Es ersetzt sie nicht, reduziert sie nicht und darf ihnen nicht widersprechen.
+
+Dieses Dokument beschreibt **keine Arbeitspakete**, **keine KI-Prompts** und **keine konkreten Implementierungsschritte**, sondern nur die empfohlene Reihenfolge und Abgrenzung der größeren Umsetzungsschritte für Version 1.
+
+## 2. Leitplanken für die Meilensteinbildung
+
+Für alle Meilensteine gelten verbindlich folgende Grundsätze:
+
+1. Es geht **ausschließlich um Version 1**.
+2. Die Zielbasis ist **genau eine Spezifikationsversion**: Technische Anlage ASV 1.09.
+3. Themen aus `Ausblick.md` sind **nicht Bestandteil** dieser Meilensteinplanung.
+4. Jeder Meilenstein muss in einem **grünen, stabilen Zwischenstand** enden.
+5. Die Architektur wird **evolutionär** weiterentwickelt, nicht in einem riskanten Komplettumbau.
+6. Fachliche Regeln, technische Parserlogik, Berichtserzeugung und Infrastruktur bleiben **klar getrennt**.
+7. Bereiche, die laut Anforderungen in V1 **nicht belastbar prüfbar** sind (`V1-N`), werden nicht versehentlich als harte Pflichtvalidierung umgesetzt. Bereiche mit Kategorie `V1-T` werden nur so weit aktiv geprüft, wie es lokal belastbar möglich ist.
+8. Die Trennung zwischen **Spec-Urteil** und **diagnostischer Weiteranalyse** ist von Anfang an architektonisch verankert, nicht erst am Ende eingeführt.
+
+## 3. Überblick über die Meilensteinfolge
+
+| Meilenstein | Titel | Hauptnutzen |
+|---|---|---|
+| **M1** | Projektfundament, Logging und Ergebnismodell | startbare CLI, stabile Grundarchitektur, Logging-Adapter, Befundmodell mit Spec-/Diagnose-Trennung |
+| **M2** | Artefaktschicht, Dateizugriff, Dateinamen und globale Rahmenregeln | sauberes Einlesen, ISO-8859-15-Basis, Dateinamensschemata, Partnersicht |
+| **M3** | EDIFACT-Serviceebene und Transportstruktur | belastbare Strukturprüfung für `UNA`, `UNB`, `UNH`, `UNT`, `UNZ` inkl. Service-Crosschecks |
+| **M4** | KKS-Auftragssatz / AUF | vollständiger eigener Prüfpfad für Auftragsdateien und KKS-Crosschecks |
+| **M5** | ASVREC-Kernmodell und feldgenaue Einzelregeln | fachlich belastbare Validierung regulärer ASV-Abrechnungen |
+| **M6** | Beziehungsregeln, Summenlogik und Storno | Falllogik, Crosschecks und strukturierte Storno-Behandlung |
+| **M7** | ASVFEH und Fehlernachrichtenlogik | sauber getrennte Validierung von Fehlerdateien und `FHL`-Segmenten |
+| **M8** | PKCS#7, Krypto und Tiefenprüfung verschlüsselter Artefakte | Prüfung transportnaher bzw. verschlüsselter Eingaben bis zur inneren Nutzlast |
+| **M9** | Bericht, Diagnose, Produktreife und Release-Härtung | final nutzbare V1 mit stabiler Ausgabe, Qualitätssicherung und Dokumentation |
+
+## 4. Detaillierte Meilensteine
+
+---
+
+## M1 – Projektfundament, Logging und Ergebnismodell
+
+### Ziel
+
+Es entsteht der tragfähige technische Sockel für die weitere Implementierung, inklusive **Logging-Adapter** und **Befundmodell mit eingebauter Spec-/Diagnose-Trennung**. Die eigentliche ASV-Fachvalidierung ist hier noch nicht enthalten. Das Grundgerüst ist so geschnitten, dass alle späteren Meilensteine ohne architektonischen Umbau darauf aufbauen können.
+
+### Inhalt
+
+- Zielstruktur gemäß hexagonaler Architektur innerhalb des bestehenden Maven-Projekts anlegen bzw. schärfen (Paketzuschnitt gemäß `technik-und-architektur.md`)
+- manuellen Bootstrap mit Constructor Injection herstellen; kein DI-Framework
+- CLI-Grundaufruf mit **genau einer Eingabedatei als Positionsargument** herstellen
+- internes Ergebnis- und Befundmodell als stabiles Grundgerüst einführen; das Befundmodell unterscheidet **von Anfang an**:
+  - **Spec-Urteil** (verbindliches Prüfurteil gemäß Spezifikation)
+  - **diagnostische Weiteranalyse** (zusätzliche Befunde, die das Spec-Urteil niemals verändern)
+- Befundarten Fehler / Warnung / Hinweis strukturell im Modell verankern
+- Befund-Metadaten als Felder vorsehen: Artefaktschicht, Prüfstufe, Prüfbereich, Segmenttyp, Segmentindex, Feld-ID, Rohwert, Position, Nachrichtenbezug, optionaler offizieller Fehlercode
+- **Logging-Adapter** einführen:
+  - SLF4J als Fassade
+  - Log4j2 als Implementierungs-Bindung
+  - konkrete Log4j2-Bindung **ausschließlich** im Bootstrap und im Logging-Adapter sichtbar
+- Trennung zwischen fachlichem Kern, Infrastruktur, Bericht und Logging von Anfang an sauber festziehen
+- Grundverhalten für Bericht- und Log-Datei im Eingabeverzeichnis etablieren (Berichtdatei `.txt`, Log-Datei `.log`, beide UTF-8)
+- Suffix-Logik `_v1`, `_v2`, … für Mehrfachläufe auf denselben Dateibasisnamen etablieren
+- Exit-Code-Grundgerüst (`0`, `1`, `2`) implementieren
+- Minimalbericht auch für Bedien- oder Zugriffsfehler vorsehen (Exit-Code `2`)
+
+### Noch nicht Ziel von M1
+
+- echte EDIFACT-Nachrichtenvalidierung
+- KKS-Feldlogik
+- ASVREC-/ASVFEH-Fachmodell
+- PKCS#7-Verarbeitung
+- inhaltliche Bericht-Gestaltung
+
+### Abnahme von M1
+
+- Anwendung ist als JAR unter Windows mit Java 21 startbar
+- Eingabedatei wird technisch entgegengenommen; falsches oder fehlendes Argument führt zu Exit-Code `2` mit Minimalbericht
+- Bericht- und Log-Datei werden im Eingabeverzeichnis mit korrekter Suffix-Logik erzeugt
+- Log4j2-Bindung ist außerhalb von Bootstrap und Logging-Adapter nicht sichtbar
+- Befundmodell trennt Spec-Urteil und Diagnose strukturell
+- Build und Tests sind grün
+
+---
+
+## M2 – Artefaktschicht, Dateizugriff, Dateinamen und globale Rahmenregeln
+
+### Ziel
+
+Die Anwendung kann lokale Eingabedateien robust lesen, technisch einordnen und als äußeres Artefakt sauber modellieren. Die globalen fachlichen Rahmenregeln und die Dateinamenskonventionen der Spezifikation sind als harte Prüfregeln umgesetzt.
+
+### Inhalt
+
+- read-only Dateisystemzugriff in einem Infrastruktur-Adapter kapseln
+- Eingaben konsequent mit **ISO 8859-15** behandeln; keine Plattform-Default- oder stillschweigende UTF-8-Dekodierung
+- äußeres Artefaktmodell aufbauen:
+  - physische Datei
+  - Dateiname
+  - Extension
+  - mutmaßliche Artefaktart
+  - erkannte Schichten
+- **automatische Dateityperkennung** und **explizite Benutzervorgabe** als gleichrangige Eingänge umsetzen; bei Widerspruch wird die Benutzervorgabe verarbeitet und zusätzlich eine Warnung erzeugt (kein Abbruch allein wegen Widerspruch)
+- **Dateinamensschemata gemäß Spezifikation als harte Prüfregeln** umsetzen:
+  - unverschlüsselt: `B<VKNR><Jahr><Quartal><Zähler>` (11 Stellen)
+  - verschlüsselt: `<IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>`
+  - Auftragsdatei: identischer Basisname wie die zugehörige verschlüsselte Datei, Endung `.AUF`
+- **Übermittlungszähler** prüfen: Wertebereich `001`–`999`, 3-stellig numerisch; V1 prüft **keine** quartalsübergreifende Folgesequenz, markiert diese Grenze aber als bewusste V1-Einschränkung im Bericht
+- **globale fachliche Rahmenregeln** umsetzen (aus `fachliche-anforderungen.md` §5.1):
+  - ISO 8859-15 als Verfahrens-Zeichensatz, nur darstellbare Zeichen
+  - ASV-Dateien werden unkomprimiert übertragen
+  - eine Datei pro Kasse, keine kassenübergreifende Bündelung
+  - keine erzwungene Sortierreihenfolge der Nachrichten innerhalb einer Datei
+- exakte Partnerdatei-Ableitung für die zugehörige `.AUF` bzw. die zugehörige Transportdatei herstellen (deterministisch, nicht heuristisch)
+- fehlende oder nicht passende Partnerdatei als Warnung modellieren, nicht als Abbruch
+
+### Noch nicht Ziel von M2
+
+- tiefe Service-Segment-Validierung
+- KKS-Feldprüfung
+- fachliche Segmentbeziehungen in ASVREC
+
+### Abnahme von M2
+
+- äußere Datei wird robust gelesen, mit ISO 8859-15 dekodiert und klassifiziert
+- Dateinamensschemata werden feldgenau geprüft
+- Übermittlungszähler-Wertebereich wird geprüft und die V1-Einschränkung ist im Bericht kenntlich
+- die vier globalen Rahmenregeln aus §5.1 sind als eigene Regelbausteine umgesetzt
+- Partnerdateien werden deterministisch gesucht, nicht heuristisch geraten
+- Widerspruch zwischen Auto-Erkennung und Benutzervorgabe wird als Warnung erzeugt, ohne Abbruch
+- Build und Tests sind grün
+
+---
+
+## M3 – EDIFACT-Serviceebene und Transportstruktur
+
+### Ziel
+
+Die Anwendung kann die EDIFACT-Hüllstruktur zuverlässig parsen und die lokalen Prüfregeln der Stufen 1 und 2 auf Service-Ebene belastbar anwenden.
+
+### Inhalt
+
+- Parsing für `UNA`, `UNB`, `UNH`, `UNT`, `UNZ`
+- `UNA` als optionales Segment behandeln; Fallback auf die ASV-konformen Standardtrennzeichen, wenn `UNA` fehlt
+- Prüfung der Trennzeichen und ihrer Gültigkeit
+- technische Segmentgrenzen, Nachrichtenhüllen und Nachrichtenanzahl bestimmen
+- **Service-Crosschecks** umsetzen:
+  - **physischer Dateiname ↔ `UNB_0020`** (`UNB_0020` ist die Übertragungsreferenz bzw. der Dateiname der Übertragung, nicht die Senderkennung)
+  - `UNB_0020` ↔ `UNZ_0020` (Referenzgleichheit von Übertragungskopf und -ende)
+  - `UNH_0062` ↔ `UNT_0062` je Nachricht (Referenzgleichheit von Nachrichtenkopf und -ende)
+  - `UNZ_0010` (Nachrichtenzähler) ↔ tatsächliche Anzahl der `UNH`/`UNT`-Paare
+  - Testindikator `UNB 0035`: Echtdaten-/Testdaten-Konsistenz mit der `E`/`T`-Kennung im physischen Dateinamen; Wert `1` nur für Testübertragungen
+- Konsistenzprüfungen, die den KKS-Auftragssatz voraussetzen (insbesondere die Abstimmung zwischen `UNB 0035`/Dateiname und KKS-`VERFAHREN_KENNUNG`), sind **nicht** Bestandteil von M3 und werden in M4 zusammen mit den KKS-Crosschecks umgesetzt
+- unbekannte oder fremde Segmente nicht vorschnell verwerfen, sondern diagnostisch sichtbar halten
+- **Spec-Urteil und diagnostische Weiteranalyse strikt trennen** (Befundklassifizierung bereits beim Erzeugen)
+- parse-nahe Sofortprüfungen bleiben auf **strukturelle und technische** Befunde beschränkt (Lesbarkeit, Zeichensatz, Trennzeichen, grobe Segment- und Feldfehler); fachliche Regeln, feldwertbezogene Plausibilitäten und Bezugskontrollen gehören **nicht** in den Parser
+
+### Noch nicht Ziel von M3
+
+- KKS-Auftragssatz im Detail
+- fachliche Feldregeln der Nutzdaten
+- Katalog- oder Bestandsprüfungen
+
+### Abnahme von M3
+
+- Service-Segmente werden robust erkannt und geparst (mit und ohne `UNA`)
+- die in M3 genannten Crosschecks sind umgesetzt und als eigene Regeln nachweisbar
+- typische Stufe-1- und Stufe-2-Strukturfehler können belastbar gemeldet werden
+- Build und Tests sind grün
+
+---
+
+## M4 – KKS-Auftragssatz / AUF
+
+### Ziel
+
+Der KKS-Auftragssatz wird als eigenständiger, vollwertiger Prüfgegenstand umgesetzt und nicht als Anhängsel der Nutzdatendatei behandelt. Eine `.AUF`-Datei kann auch **eigenständig** (als einzige Eingabedatei pro Lauf) validiert werden.
+
+### Inhalt
+
+- Parser für den festen KKS-Auftragssatz aufbauen
+- **vollständige Umsetzung der KKS-Feldregeln** gemäß `fachliche-anforderungen.md` §9. Die nachfolgende Liste ist nicht abschließend, sondern nennt zentrale Anker; maßgeblich ist §9.
+- zentrale Festwerte und Strukturprüfungen:
+  - `IDENTIFIKATOR = 500000`
+  - `VERSION = 01`
+  - `LÄNGE_AUFTRAG = 00000348`
+  - `SEQUENZ_NR = 000` (keine Teillieferungen)
+  - `VERFAHREN_KENNUNG`: Stelle 20 `E`/`T`, Stellen 21–23 `ASV`, Stelle 24 `0`
+  - `VERFAHREN_KENNUNG_SPEZIFIKATION` als **Kann-Feld**: Blank zulässig; wenn belegt, nur aus der definierten Wertemenge (`ASVA0` für Abrechnung, `ASVF0` für Fehlermeldung)
+  - `TRANSFER_NUMMER`: Wertebereich `001`–`999`
+  - `DATUM_ERSTELLUNG`: 14-stellig `JJJJMMTThhmmss`, formal prüfen
+  - `DATEIVERSION = 000000`
+  - `KORREKTUR = 0`
+  - `FEHLER_NUMMER = 000000`, `FEHLER_MASSNAHME = 000000`
+  - `ZEICHENSATZ = I5` (formaler Anker für die ISO-8859-15-Annahme der gesamten Anwendung)
+  - `KOMPRIMIERUNG = 00`
+  - `VERSCHLÜSSELUNGSART = 03`
+  - `ELEKTRONISCHE_UNTERSCHRIFT = 03`
+- **Kommunikationspartner-Felder** (`ABSENDER_EIGNER`, `ABSENDER_PHYSIKALISCH`, `EMPFÄNGER_NUTZER`, `EMPFÄNGER_PHYSIKALISCH`): strukturell und formal auf IK-Format prüfen. Eine inhaltliche Kommunikationspartnerprüfung ist ohne Referenzbestände in V1 nicht belastbar möglich und daher nicht Gegenstand von M4 (`V1-T`)
+- Kann-Felder des KKS nach Nichtbelegungsregeln prüfen:
+  - numerisch → Nullfüllung (`HEX 30`)
+  - alphanumerisch → Blankfüllung (`HEX 20`)
+- **KKS-Crosschecks**:
+  - `TRANSFER_NUMMER` ↔ Zähler im physischen Dateinamen
+  - **Dateinamensbezug** (Begriffsklärung):
+    - der **physische Dateiname** der verschlüsselten Übertragungsdatei folgt dem Schema `<IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>`
+    - die zugehörige **Auftragsdatei** trägt denselben physischen Basisnamen und endet auf `.AUF`
+    - `UNB_0020` trägt, sobald die EDIFACT-Schicht vorliegt, die Übertragungsreferenz und entspricht dem Dateinamen der Übertragung
+    - die **KKS-`DATEINAME`**-Angabe im Auftragssatz entspricht dem **unverschlüsselten** Dateinamen nach dem Schema `B<VKNR><Jahr><Quartal><Zähler>`
+    - zu prüfen sind: KKS-`DATEINAME` gegen den aus Schema und Kontext abgeleiteten unverschlüsselten Dateinamen sowie – soweit beide Schichten vorliegen – die Konsistenz zwischen physischem Dateinamen der Übertragung, `UNB_0020` und KKS-`DATEINAME`
+  - `DATEIGRÖSSE_NUTZDATEN` gegen die tatsächliche Bytegröße der unverschlüsselten Nutzdatendatei, soweit die unverschlüsselte Schicht lokal vorliegt
+  - `DATEIGRÖSSE_ÜBERTRAGUNG` gegen die tatsächliche Bytegröße der verschlüsselten Übertragungsdatei
+  - Echtdaten-/Testdaten-Konsistenz zwischen Dateiname, KKS-`VERFAHREN_KENNUNG` und – soweit vorhanden – `UNB 0035`
+
+### Noch nicht Ziel von M4
+
+- vollständige fachliche ASVREC-Regelvalidierung
+- ASVFEH-Fachlogik
+- PKCS#7-Tiefenprüfung
+
+### Abnahme von M4
+
+- `.AUF`-Dateien sind eigenständig validierbar
+- die Regeln aus `fachliche-anforderungen.md` §9 sind umgesetzt
+- KKS-Festwerte und Feldlogik sind belastbar geprüft
+- KKS-Crosschecks funktionieren technisch sauber
+- AUF-bezogene Befunde sind im Ergebnis klar von EDIFACT-Nutzdaten-Befunden getrennt
+- Build und Tests sind grün
+
+---
+
+## M5 – ASVREC-Kernmodell und feldgenaue Einzelregeln
+
+### Ziel
+
+Reguläre ASV-Abrechnungsnachrichten (`ASVREC`) werden fachlich auf Segment- und Feldebene belastbar validierbar, soweit dies lokal ohne Referenzbestände möglich ist.
+
+### Inhalt
+
+- kanonisches internes Modell für `ASVREC` aufbauen
+- Segmentabbildung für die ASVREC-Nutzsegmente gemäß Spezifikation: `IFA`, `DGN`, `LEA`, `SAC`, `GEN`, `OPA`, `REA`, `IVA`
+- feldgenaue Regeln gemäß Fachlichen Anforderungen umsetzen, soweit in V1 lokal belastbar
+- Muss-/Kann-Logik und Vorkommensregeln pro Segment und Feld umsetzen
+- formale Prüfungen für Typ, Länge, Format, Schlüsselwerte und Sonderformate umsetzen
+- **Versichertennummer-Strukturprüfung** (`IVA 8.3.1`) umsetzen:
+  - Stelle 1: Alpha `A`–`Z` ohne Umlaute
+  - Stellen 2–9: numerisch
+  - Stelle 10: Prüfzifferstelle vorhanden (keine algorithmische Prüfziffernvalidierung in V1)
+- zentrale Sonderregeln und Ausnahmen korrekt berücksichtigen – diese **dürfen nicht fälschlich als Fehler gemeldet werden**:
+  - **Geburtsdatum im Ersatzverfahren** (`IVA 8.4.3`): im Format `JJJJMMTT` sind beliebige numerische Werte zulässig, zusätzlich die Platzhalter `00` (unbekannter Tag), `0000` (unbekannter Tag und Monat) und `00000000` (vollständig unbekannt); eine Datumsplausibilisierung in diesem Feld ist unzulässig
+  - **negative numerische Werte**: das führende Minuszeichen zählt nicht zur maximalen Feldlänge
+  - **Dezimalzeichen `,`** zählt nicht zur maximalen Feldlänge
+  - **Pseudo-GOP `88999` sowie regionale Pseudo-GOP** sind für Sachkosten ohne Sachzusammenhang zulässig
+  - **GOÄ-Sonderfall**: in `3/3.2.1` wird die Pseudo-GOP übertragen, in `3/3.2.5` die zugehörige GOÄ-Ziffer
+  - **obsolete Muss-Felder `4/4.2.4` und `4/4.2.5`**: füllpflichtig mit beliebigem Inhalt, aber **nicht ausschließlich Leerzeichen**; inhaltlich werden diese Felder nicht geprüft
+- **Vertretungs-Teamebene `4`**: Die Spezifikation legt fest, dass bei Teamebene `4` die Teamebene des Vertretenen maßgeblich ist. Eine belastbare Prüfung dieser Regel setzt einen Abgleich mit dem ASV-Verzeichnis voraus und ist in V1 ohne Referenzbestände nicht möglich (`V1-N`). V1 erzwingt deshalb insbesondere keine Plausibilitäten auf Teamebene `4` und markiert diesen Bereich als bewusst nicht geprüft.
+- ausdrücklich **keine** referenzbestandsabhängigen Prüfungen erzwingen (`V1-N`-Bereich: ICD, OPS, IK, BSNR, LANR, Teamnummer inhaltlich)
+- Bereiche mit `V1-N` im Bericht als „bewusst nicht geprüft" kenntlich machen
+
+### Noch nicht Ziel von M5
+
+- fallübergreifende bzw. komplexe Crosschecks
+- Storno-Sonderstruktur
+- ASVFEH
+- PKCS#7
+
+### Abnahme von M5
+
+- reguläre `ASVREC`-Nachrichten können segment- und feldgenau validiert werden
+- die genannten Sonderwerte und Ausnahmen werden nicht fälschlich als Fehler behandelt
+- die Versichertennummer-Strukturprüfung ist umgesetzt
+- lokal nicht belastbar prüfbare Bereiche bleiben sauber abgegrenzt und als `V1-N` markiert
+- das kanonische Modell ist stabil genug für Beziehungsregeln im nächsten Meilenstein
+- Build und Tests sind grün
+
+---
+
+## M6 – Beziehungsregeln, Summenlogik und Storno
+
+### Ziel
+
+Die fallinterne Logik von ASV-Abrechnungen wird vollständig genug, um reguläre Rechnungen und Storno-Fälle fachlich konsistent zu beurteilen.
+
+### Inhalt
+
+- segmentübergreifende Crosschecks umsetzen, insbesondere:
+  - `DGN` erforderlich bei regulärer Rechnung (`REA 7.2.4 = 0`)
+  - `LEA` erforderlich bei regulärer Rechnung
+  - Summenprüfung Rechnungsbetrag (`REA`) gegen `LEA` und `SAC`, soweit ohne externe Bestände lokal möglich
+  - Überweiserkontext ↔ Diagnoseart (`IFA 1.3.1` / `DGN 2.2.5`)
+  - externer und interner Überweiser nicht gleichzeitig (`IFA 1.3.1` / `1.3.2`)
+  - Pflicht-`GEN` bei bestimmten GOPs
+- Regeln für Pseudo-GOP, GOÄ-Sonderfall und Sachkosten-Sonderkonstellationen umsetzen, soweit lokal belastbar
+- Konsistenzprüfung zur globalen Regel „eine Datei pro Kasse" auf Basis der lokal verfügbaren Kassenbezüge (Andockstelle an die globale Rahmenregel aus M2)
+- **Storno als eigene Strukturvariante von `ASVREC`** sauber modellieren:
+  - reduzierte Segmentstruktur: nur die in der Spezifikation für Storno vorgesehenen Muss-Segmente und Muss-Felder
+  - bei Storno **unzulässige** Segmente gemäß Spezifikation: `DGN`, `LEA`, `SAC`, `GEN`, `OPA` – ihr Vorhandensein ist ein Fehler
+  - Rechnungskennzeichen Storno (`REA 7.2.4 = 1`)
+  - Rechnungsbetrag bei Storno `REA 7.2.1 = 0,00`
+  - Bezug auf die ursprüngliche Rechnungsnummer, soweit lokal prüfbar
+- saubere Vermeidung, dass Storno-Pflichten als „normale Rechnungspflichten" missbraucht werden und umgekehrt
+
+### Noch nicht Ziel von M6
+
+- Validierung von `ASVFEH`
+- PKCS#7-Tiefenprüfung
+
+### Abnahme von M6
+
+- reguläre Rechnungen und Storno-Nachrichten werden sauber unterschieden
+- die in M6 genannten segmentübergreifenden ASVREC-Regeln greifen
+- Summen- und Strukturfehler werden fachlich nachvollziehbar ausgewiesen
+- Storno wird als eigene Variante behandelt; bei Storno unzulässige Segmente werden erkannt
+- Build und Tests sind grün
+
+---
+
+## M7 – ASVFEH und Fehlernachrichtenlogik
+
+### Ziel
+
+Fehlernachrichten (`ASVFEH`) werden als eigener Nachrichtentyp mit eigener Struktur und eigenen Regeln vollständig separat validiert.
+
+### Inhalt
+
+- eigenes kanonisches Modell für `ASVFEH` einführen
+- beide Strukturvarianten unterstützen:
+  - **eigenständige Fehlerdatei** (typisch Stufe 1): `UNB`, `UNH` mit Nachrichtentyp `ASVFEH`, `FHL`, `UNT`, `UNZ`
+  - **eingebettete Fehlernachricht mit Originalnutzdaten** (typisch Stufen 2–4): `UNH`, Originalnutzdatensegmente, `FHL`, `UNT`
+- `FHL`-Segmentlogik umsetzen (Spezifikation sieht bis zu 99 Vorkommen vor)
+- Prüfung von Fehlercode, Fehlertext, Referenzen, Storno-/Korrekturkennzeichen und weiteren `FHL`-Feldern, soweit lokal belastbar
+- Regel abbilden: Kann-Datenelemente im `FHL` werden zu Muss-Datenelementen, **wenn** ihre Ermittelbarkeit aus der Fehlersituation belastbar ableitbar ist. V1 setzt dies nur dort als Fehler um, wo diese Ableitbarkeit aus der vorliegenden Datei wirklich gegeben ist.
+- **Umgang mit Originalnachricht** explizit umsetzen:
+  - die mitgelieferte Originalnachricht wird **nicht** als eigenständiger ASVREC-Validierungsgegenstand behandelt
+  - die Abwesenheit der Originalnachricht bei Prüfstufen 2–4 ist **kein Fehler**, sondern höchstens ein Hinweis, da die Originalnutzdaten laut Spezifikation nicht lesbar oder nicht syntaxkonform übertragbar gewesen sein dürfen
+  - die Verfahrensregel „eine Fehlernachricht darf nicht mit einer Fehlernachricht beantwortet werden" wird **nicht** als Validierungsregel umgesetzt, da sie an einer einzelnen isoliert übergebenen Datei nicht prüfbar ist (`V1-N`)
+- Vorrang spezifischer offizieller Fehlercodes vor Sammelcodes (`xx999`, `3A998`, `4A998`) berücksichtigen
+
+### Noch nicht Ziel von M7
+
+- PKCS#7-Tiefenprüfung
+- finale Berichtsveredelung
+
+### Abnahme von M7
+
+- `ASVFEH` ist sauber von `ASVREC` getrennt
+- beide `ASVFEH`-Strukturvarianten werden korrekt erkannt
+- `FHL`-Segmente sind feldgenau modelliert und strukturell für bis zu 99 Vorkommen unterstützt
+- das Fehlen der Originalnachricht bei Stufen 2–4 erzeugt keinen harten Fehler
+- offizielle Fehlercodebezüge können belastbar an Befunde angehängt werden; Sammelcodes werden nur genutzt, wenn kein spezifischerer offizieller Code einschlägig ist
+- Build und Tests sind grün
+
+---
+
+## M8 – PKCS#7, Krypto und Tiefenprüfung verschlüsselter Artefakte
+
+### Ziel
+
+Die Anwendung kann verschlüsselte bzw. transportnahe Artefakte technisch verarbeiten und – soweit Material nutzbar bereitgestellt wurde – bis zur inneren Nutzlast durchsteigen. **Die Tiefenprüfung nutzt die bereits in M3–M7 gebaute Validierungskette erneut**; es entsteht keine zweite, parallele Validierungslogik.
+
+### Inhalt
+
+- Krypto-Adapter hinter stabilen Ports einführen; Krypto-Verarbeitung erfolgt **innerhalb der Java-Anwendung**, keine externen Tools oder Binaries
+- explizite CLI-Übergabe von Schlüssel- und Passwortmaterial anbinden (konkrete Optionsnamen in der README dokumentiert)
+- Basisprüfung verschlüsselter Artefakte auch **ohne** nutzbares Material ermöglichen
+- Fallback-Verhalten sauber umsetzen: **Warnung statt Totalabbruch**, wenn Material technisch nicht nutzbar ist
+- nach erfolgreicher Entschlüsselung automatisch bis zur inneren fachlichen Schicht weiterarbeiten, indem die bereits bestehende Validierungskette aus M3–M7 auf die entschlüsselte Nutzlast angewendet wird
+- Mindestalgorithmusprüfungen gemäß technischem Soll-Rahmen modellieren, insbesondere:
+  - PKCS#7 als Containerformat
+  - AES-256-CBC als Session Key
+  - RSA 4096 Bit als Interchange Key
+  - SHA256withRSAandMGF1 / PSS
+  - RSA-Exponent Fermat-4 (`2^16 + 1`)
+- Nicht-PSS-Altverfahren müssen in V1 nicht aktiv unterstützt werden, dürfen aber als erkannte Abweichung gemeldet werden
+- Abweichungen sauber als technische Befunde modellieren
+- Krypto-Integration bleibt sauber von Domain und Application entkoppelt; Krypto-Typen sind außerhalb des Krypto-Adapters und des Bootstrap nicht sichtbar
+
+### Noch nicht Ziel von M8
+
+- zusätzliche Transportkanäle
+- E-Mail- oder Serverintegration
+- Mehrdateimodus
+
+### Abnahme von M8
+
+- verschlüsselte Artefakte sind technisch analysierbar
+- mit gültigem Material ist Tiefenprüfung bis zur Nutzlast möglich; das Ergebnis ist konsistent zu dem, was eine Direktvalidierung der unverschlüsselten Datei liefern würde
+- ohne nutzbares Material erfolgt nachvollziehbare Basisprüfung mit Warnung, kein Totalabbruch
+- Krypto-Integration ist entkoppelt
+- Build und Tests sind grün
+
+---
+
+## M9 – Bericht, Diagnose, Produktreife und Release-Härtung
+
+### Ziel
+
+Die bis dahin umgesetzte Funktionalität wird zu einer sauberen, benutzbaren und abnahmereifen Version 1 zusammengeführt.
+
+### Inhalt
+
+- finalen hierarchischen Bericht stabilisieren:
+  - Datei
+  - Schichten
+  - Nachrichten/Fälle
+  - Befunde
+- strukturierte Bestandsinformationen in den Bericht aufnehmen: erkannter Dateityp, erkannte Schichten, Anzahl Nachrichten/Fälle, relevante Kopfdaten, Übermittlungszähler, spec-konformes Prüfurteil, zusätzliche diagnostische Auffälligkeiten
+- klare Trennung zwischen **Spec-Urteil** und **diagnostischer Weiteranalyse** final durchziehen (architektonisch seit M1 vorhanden, hier nur in der Darstellung konsolidiert)
+- Befunde mit Metadaten und – soweit eindeutig – offiziellen Fehlercodes anreichern; Vorrangregel für Sammelcodes einhalten
+- Konsolenausgabe und Berichtdatei fachlich gleichziehen
+- technisches Logging sauber vom Bericht trennen
+- README und Nutzungsdokumentation vervollständigen, inklusive CLI-Optionsnamen und der PKCS#7-Materialübergabe
+- umfangreiche End-to-End-Testartefakte ergänzen: Parser-, KKS-, ASVFEH- und Storno-Fälle mit synthetischen, anonymisierten Testdaten
+- letzte Robustheits- und Randfalllücken schließen
+
+### Quality-Gates für Version 1 (verbindlich)
+
+- Build grün
+- alle Tests grün
+- **Coverage gesamtprojektweit ≥ 85 %**
+- **PIT-Mutation-Score gesamtprojektweit ≥ 70 %**
+- differenzierte Zielschwellen gemäß `technik-und-architektur.md`:
+
+| Bereich | Coverage | Mutation |
+|---|---|---|
+| `domain` | ≥ 95 % | ≥ 85 % |
+| `application` | ≥ 90 % | ≥ 80 % |
+| `adapter.out.*` | ≥ 90 % | ≥ 75 % |
+| `adapter.in.cli` | ≥ 80 % | ≥ 60 % |
+| `bootstrap` | ausgenommen | ausgenommen |
+
+- Abweichungen von den Schwellwerten sind nur mit dokumentierter Begründung zulässig
+
+### Noch nicht Ziel von M9
+
+- GUI
+- Batch-Verarbeitung
+- Mehrversionssupport
+- Referenzdatenbestände
+- spätere Erweiterungen aus `Ausblick.md`
+
+### Abnahme von M9
+
+- Version 1 ist fachlich und technisch in sich geschlossen nutzbar
+- Bericht und Logging sind stabil, verständlich und sauber getrennt
+- Spec-Urteil wird nie durch Diagnose „grün gerechnet"
+- alle Quality-Gates sind erreicht oder bewusst dokumentiert abgewichen
+- das Projekt ist bereit für nachgelagerte Feinschnitte in Arbeitspakete
+
+## 5. Empfohlene Umsetzungslogik für die spätere Arbeitspaketbildung
+
+Aus dieser Meilensteinstruktur ergibt sich für die spätere Arbeitspaketbildung folgende sinnvolle Logik:
+
+1. Zuerst immer den **tragfähigen Unterbau** herstellen – inklusive Logging und Befundmodell mit Spec-/Diagnose-Trennung.
+2. Danach die **äußere technische Struktur**, die **globalen Rahmenregeln** und den **KKS-Auftragssatz** stabilisieren.
+3. Erst dann die **fachliche Tiefe von ASVREC** aufbauen.
+4. Storno und ASVFEH nicht vermischen, sondern als **eigene Prüfdimensionen** schneiden.
+5. PKCS#7 erst aufsetzen, wenn die innere Nutzlastvalidierung bereits stabil steht; die bestehende Kette wird wiederverwendet.
+6. Produktreife, Bericht, Doku und Qualitäts-Härtung am Ende konsolidieren.
+
+## 6. Definition of Done über alle Meilensteine hinweg
+
+Ein Meilenstein gilt nur dann als sinnvoll abgeschlossen, wenn mindestens die folgenden Punkte erfüllt sind:
+
+- der Stand ist **fachlich und technisch konsistent** zu den Grunddokumenten
+- Build und zugehörige Tests sind **grün**
+- der Meilenstein erzeugt keinen architektonischen Widerspruch zu den Grunddokumenten
+- nicht prüfbare `V1-N`- und nur teilprüfbare `V1-T`-Bereiche wurden nicht versehentlich als harte Pflichtprüfung umgesetzt
+- keine Elemente aus späteren Ausbaustufen wurden unbemerkt in Version 1 hineingezogen
+- die im jeweiligen Meilenstein genannten Abnahmekriterien sind erfüllt
+- der Stand ist stabil genug, um daraus anschließend **Arbeitspakete** abzuleiten
+
+Die finalen Quality-Gates für Version 1 (Coverage, Mutation, Zielschwellen pro Paket) gelten am Ende von M9. Zwischenmeilensteine müssen lediglich grün sein, nicht die finalen Schwellwerte vorwegnehmen.
+
+## 7. Zusammenfassung
+
+Die Implementierung von Version 1 sollte nicht entlang technischer Zufälle, sondern entlang einer klaren fachlich-technischen Reifung erfolgen:
+
+- zuerst **Grundgerüst, Logging und Befundmodell mit Spec-/Diagnose-Trennung**,
+- dann **Artefaktschicht, Dateinamen und globale Rahmenregeln**,
+- dann **Service- und KKS-Ebene**,
+- danach **ASVREC mit Beziehungslogik und Storno**,
+- anschließend **ASVFEH**,
+- danach **PKCS#7-Tiefenprüfung unter Wiederverwendung der bestehenden Kette**,
+- und zum Schluss **Bericht, Qualität und Release-Härtung**.
+
+Damit entsteht eine Meilensteinfolge, die klein genug für kontrollierte Weiterentwicklung bleibt, aber groß genug ist, um daraus später präzise und in sich geschlossene Arbeitspakete abzuleiten.
+
+## 8. Dokumenthistorie
+
+| Version | Wesentliche Änderungen |
+|---|---|
+| v1 | Erstfassung mit Meilensteinfolge M1–M9 |
+| v2 | Logging-Adapter und Spec-/Diagnose-Trennung als Fundament in M1 verankert; Dateinamensschemata und globale Rahmenregeln in M2 ergänzt; Service-Crosschecks in M3 vollständiger; KKS-Regelsatz in M4 erweitert und eigenständige `.AUF`-Validierbarkeit klargestellt; Sonderregeln in M5 ergänzt; Umgang mit Originalnachricht in M7 präzisiert; Wiederverwendung der Validierungskette in M8 explizit; Quality-Gates in M9 mit Zahlen. |
+| v3 | Zweck entschärft und Rangfolge der Grunddokumente klargestellt (Spec.docx als Wahrheit; `meilensteine.md` strukturiert lediglich). M3: Crosscheck `physischer Dateiname ↔ UNB_0020` korrekt als Übertragungsreferenz benannt (nicht „Senderkennung"); Vorgriff auf KKS-`VERFAHREN_KENNUNG` aus M3 entfernt und nach M4 verschoben. M4: Dateinamensbezug (physischer Dateiname, `UNB_0020`, KKS-`DATEINAME`, `.AUF`-Basisname) sauber begrifflich getrennt; unscharfe „bzw."-Formulierung ersetzt. M5: regionale Pseudo-GOP neben `88999` ausdrücklich aufgenommen; Vertretungs-Teamebene `4` als `V1-N` gekennzeichnet statt als aktive Prüfung; `NAD`-Hinweis entfernt. Gesamtes Dokument: in v2 eingeführte Zwischen-Quality-Gates (Coverage/Mutation pro Meilenstein) entfernt, da nicht aus den Grunddokumenten folgend; finale Gates bleiben in M9 erhalten. `V1-T`-Sprachregelung in den Leitplanken präzisiert. Kleinere sprachliche Glättungen. |

docs/specs/technik-und-architektur.md

@@ -0,0 +1,859 @@
+# Technik und Architektur
+
+> **Dokumentversion:** v5 (final)
+> **Stand:** 08.04.2026
+> **Status:** verbindlicher Architektur-Soll-Rahmen für die Implementierung von Version 1
+> **Bezugsspezifikation:** Technische Anlage ASV 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026
+
+## Zweck des Dokuments
+
+Dieses Dokument beschreibt den technischen und architektonischen Soll-Rahmen für das Projekt **ASV-Format-Validator** in **Version 1**.
+
+Dieses Dokument ist **kein Ersatz** für die offizielle ASV-Spezifikation. Bei jeder fachlichen oder technischen Kollision gilt stets die **Technische Anlage ASV 1.09, Stand 09.10.2025, anzuwenden ab Leistungserbringungsquartal 2/2026** als maßgebliche Wahrheit. Dieses Dokument konkretisiert nur die technische Umsetzung für Version 1.
+
+Nicht Bestandteil dieses Dokuments sind:
+
+- konkrete Implementierungs-Prompts für eine umsetzende KI
+- Arbeitspakete
+- Java-Code
+- die Datei `/docs/specs/fachliche-anforderungen.md`
+- GUI-Umsetzung
+- Server-, Container- oder Web-Betrieb
+- Mehrversionssupport der ASV-Spezifikation
+
+Version 1 verfolgt ein bewusst schlankes Zielbild: Eine **lokale Windows-CLI-Anwendung** soll **genau eine Datei pro Lauf** so robust wie technisch vertretbar analysieren, validieren und darüber berichten.
+
+## Zielversion der Spezifikation
+
+Version 1 richtet sich fachlich und technisch auf genau **eine** ASV-Zielversion aus:
+
+- **Technische Anlage 1.09**
+- **Stand 09.10.2025**
+- **anzuwenden ab Leistungserbringungsquartal 2/2026**
+
+Mehrversionsunterstützung ist nicht Scope von Version 1.
+
+Die Hinweis- und Erläuterungssektionen der Spezifikation sind **verbindlicher Regelinput**. Dazu gehören insbesondere auch Sonderregeln und Ausnahmen, etwa:
+
+- Pseudo-GOP `88999` bzw. regionale Pseudo-GOP
+- GOÄ-Sonderfall
+- Vertretungs-Teamebene `4`
+- obsolet gewordene, aber weiterhin zu füllende Felder `4/4.2.4` und `4/4.2.5`
+- Geburtsdatum-Sonderwerte im Ersatzverfahren
+- Regeln zu negativen numerischen Werten und Dezimaltrennzeichen
+
+## Technisches Zielbild
+
+Die Anwendung ist in Version 1 ein **reines CLI-Werkzeug** mit folgenden Eigenschaften:
+
+- lokaler Betrieb unter **Windows**
+- Auslieferung als **eine direkt startbare JAR-Datei**
+- Laufzeitvoraussetzung: **Java JDK 21**
+- genau **eine lokale Eingabedatei pro Programmaufruf**
+- Pflichtübergabe des Eingabepfads als **Positionsargument**
+- kein Serverbetrieb, keine Containerisierung, keine Web-Anwendung
+- kein stdin, keine Batch-Verarbeitung, keine Verzeichnisverarbeitung
+
+Die Architektur von Version 1 muss jedoch bereits so geschnitten sein, dass in einer späteren Version eine **JavaFX-GUI** ohne grundlegenden Umbau an denselben Kern angebunden werden kann.
+
+## Architekturprinzipien
+
+### Grundsätze
+
+Für Version 1 gelten folgende Architekturprinzipien:
+
+- **hexagonale Architektur** innerhalb des bestehenden Maven-Projekts
+- **keine neue Maven-Modulzerlegung als Sollvorgabe**, aber klare Pakettrennung
+- **evolutionäre Weiterentwicklung** des bestehenden Projekts in kleinen, sicheren Schritten
+- **kein schwergewichtiges Application-Framework**
+- **kein Dependency-Injection-Framework**
+- Verdrahtung erfolgt **manuell per Constructor Injection** im Bootstrap
+- **plain Java 21** plus gezielt eingesetzte Bibliotheken
+- externe Bibliotheken sind erlaubt, wenn sie die Lösung robuster, klarer oder kleiner machen
+- Design Patterns werden bewusst und gezielt eingesetzt, aber nie als Selbstzweck
+
+### Technische Entkopplung
+
+Der innere Kern bleibt strikt frei von Infrastruktur- und Technikdetails.
+
+**Nicht** in `domain` oder `application`:
+
+- CLI
+- Logging-Framework, konkrete Logging-Bindung oder Log-Konfiguration
+- Dateisystemzugriffe
+- PKCS#7-/Krypto-Bibliotheken
+- konkrete Parser-Bibliotheken
+- Berichtserzeugung als Text
+- Konsolen- oder Dateiausgabe
+
+Diese Dinge gehören ausschließlich in Adapter bzw. Infrastruktur. Insbesondere darf die konkrete Log4j2-Bindung niemals außerhalb des Bootstrap- oder Logging-Adapters sichtbar werden.
+
+## Gewünschte Paketstruktur
+
+Die Soll-Struktur innerhalb des bestehenden Projekts orientiert sich explizit an einer hexagonalen Trennung, zum Beispiel entlang folgender Pakete:
+
+- `domain`
+- `application`
+- `adapter.in.cli`
+- `adapter.out.filesystem`
+- `adapter.out.parsing`
+- `adapter.out.crypto`
+- `adapter.out.reporting`
+- `adapter.out.logging`
+- `bootstrap`
+
+Die exakten Paketnamen dürfen projektnah angepasst werden, die fachlich-technische Trennung muss aber klar erkennbar bleiben.
+
+## Verantwortlichkeiten der Schichten
+
+### Domain
+
+Die Domain enthält die stabilen fachlich-technischen Kernmodelle und Regeln, insbesondere:
+
+- kanonisches internes Modell der ASV-Inhalte
+- Befundmodell
+- Schichtmodell für Artefakte, technische Struktur und Fachsicht
+- gemeinsame Begriffe, Wertobjekte und Regelabstraktionen
+- keine Infrastrukturabhängigkeiten
+
+### Application
+
+Die Application orchestriert den Validierungslauf, insbesondere:
+
+- Annahme eines Validierungsauftrags
+- Steuerung der Erkennung, des Einlesens, des Parsings und der Validierung
+- Trennung zwischen **Spec-konformem Prüfurteil** und **zusätzlicher diagnostischer Weiteranalyse**
+- Zusammenführen aller Teilbefunde
+- Erzeugung eines strukturierten Gesamtergebnisses
+- keine textnahe Ausgabe, kein direktes Loggingformat, keine Dateiausgabe
+
+### Adapter in
+
+Der CLI-Adapter übernimmt ausschließlich ein- und ausgangsnahe Verantwortung:
+
+- Auslesen der CLI-Parameter
+- Übergabe an die Application
+- Schreiben des Berichts in Konsole und Berichtdatei
+- technische Initialisierung
+
+### Adapter out
+
+Adapter out kapseln technische Details, zum Beispiel:
+
+- Dateisystemzugriffe
+- Einlesen von Dateien inklusive Zeichensatzbehandlung
+- PKCS#7-/Krypto-Verarbeitung
+- Auftragsdatei-/Nutzdatendatei-Erkennung
+- Parser für technische Dateischichten
+- Bericht-Rendering als Text
+- Logging-Anbindung
+
+### Bootstrap
+
+Der Bootstrap startet die Anwendung, verdrahtet die Komponenten **manuell per Constructor Injection** und bleibt dünn.
+
+## Laufzeit- und Betriebsmodell
+
+### Grundverhalten
+
+Version 1 arbeitet pro Lauf:
+
+- mit **genau einer Eingabedatei**
+- **read-only** bezüglich der Eingabedatei
+- **zustandslos** im Sinne der fachlichen Verarbeitung
+- ohne Persistenz, Cache oder Historie
+- mit **immer erzeugtem Bericht**, auch bei frühen technischen Fehlern, soweit irgendetwas belastbar feststellbar ist
+
+### Ausgabeartefakte
+
+Version 1 erzeugt pro Lauf genau zwei Ausgabedateien im **Verzeichnis der Eingabedatei**:
+
+- eine **Berichtdatei** im Format `.txt`
+- eine **Log-Datei** im Format `.log`
+
+Zusätzlich wird der Validierungsbericht in die **Konsole** geschrieben.
+
+Sind für dieselbe Eingabedatei bereits Bericht- oder Log-Dateien vorhanden, werden neue Dateinamen mit laufendem Suffix erzeugt, zum Beispiel:
+
+- `_v1`
+- `_v2`
+- `_v3`
+
+Die Zählung erfolgt **pro Eingabedatei/Basisname**. Da Version 1 nur einen Lauf pro Aufruf kennt und kein Mehrbenutzerbetrieb vorgesehen ist, werden Race Conditions bei paralleler Ausführung auf derselben Eingabedatei nicht behandelt.
+
+### Zeichensätze
+
+- **Eingabedateien** werden grundsätzlich als **ISO 8859-15** verarbeitet.
+- Die Anwendung darf keine stillschweigende UTF-8- oder Plattform-Default-Dekodierung verwenden.
+- Bei Artefakten, deren eigene Metadaten einen Zeichensatzbezug enthalten, ist zusätzlich die Konsistenz zu diesen Metadaten zu prüfen.
+- **Bericht- und Log-Dateien** werden in **UTF-8** geschrieben.
+
+Hinweis: Eine tatsächlich abweichende Kodierung ist auf Byte-Ebene nicht immer sicher beweisbar. V1 behandelt daher primär Verstöße gegen **erwartete Zeichensatzfestlegungen** und **nicht darstellbare Inhalte** als Befunde.
+
+### EDIFACT-Trennzeichen und UNA
+
+Die Anwendung muss das **UNA-Segment** als optionales Service-Segment korrekt verarbeiten.
+
+Für ASV gelten gemäß Spezifikation folgende Trennzeichen:
+
+| Funktion | Zeichen | Dezimalcode |
+|---|---|---|
+| Segmentende | IS4 | 28 |
+| Datenelementtrennung | IS3 | 29 |
+| Gruppenelementtrennung | IS1 | 31 |
+| Dezimalzeichen | `,` | – |
+
+Für Version 1 gilt:
+
+- Ist `UNA` vorhanden, werden dessen Trennzeichenvorgaben geparst und geprüft.
+- Ist `UNA` nicht vorhanden, arbeitet der Parser mit den **ASV-konformen Standardtrennzeichen**.
+- Abweichende oder fehlerhafte Trennzeichenvorgaben sind als technische Befunde zu melden.
+
+## Unterstützte Eingabeartefakte
+
+Version 1 verarbeitet lokale Datei-Artefakte auf Dateisystemebene, insbesondere:
+
+- ASV-Nutzdatendateien mit `ASVREC`
+- ASV-Fehlernachrichten mit `ASVFEH`
+- Storno-Nachrichten als spezielle Ausprägung von `ASVREC`
+- Auftragsdateien (`.AUF`, KKS-Auftragssatz)
+- verschlüsselte bzw. transportnahe PKCS#7-Artefakte
+
+Nicht im Scope von Version 1:
+
+- E-Mail-Dateien wie `.eml` oder `.msg`
+- Server-/Transportintegration
+- Verzeichnis- oder Mehrdateiverarbeitung als eigener Betriebsmodus
+- automatische Korrektur oder Rewrite von Eingabedateien
+
+## Dateierkennung und Modussteuerung
+
+### Automatische Erkennung
+
+Der Validator soll Dateityp und verarbeitbare Schichten **automatisch erkennen**, soweit das zuverlässig möglich ist.
+
+### Explizite Benutzersteuerung
+
+Der Benutzer darf den Dateityp bzw. Prüfmodus **explizit vorgeben**. Diese Vorgabe ist maßgeblich.
+
+Wenn die automatische Erkennung zu einem anderen Ergebnis kommt als die Benutzervorgabe:
+
+- wird **gemäß Benutzervorgabe verarbeitet**
+- wird zusätzlich eine **Warnung** ausgegeben
+- erfolgt **kein Abbruch allein wegen dieses Widerspruchs**
+
+Wenn ein Dateityp nicht hinreichend sicher erkennbar ist und keine explizite Vorgabe vorliegt:
+
+- erfolgt eine **generische Basisprüfung**
+- wird mindestens eine **Warnung** ausgegeben
+
+## Dateinamenskonventionen
+
+Die Dateinamenschemata gemäß Spezifikation Abschnitt 3.5 sind **harte Prüfregeln** und werden vom Validator geprüft.
+
+### Unverschlüsselte Datei
+
+Schema: `B<VKNR><Jahr><Quartal><Zähler>` (11 Stellen)
+
+| Stelle | Inhalt |
+|---|---|
+| 1 | Konstante `B` für ASV |
+| 2–6 | VKNR oder `00000` bei Direktabrechnung |
+| 7 | Jahresbuchstabe (`A` = 2014, `B` = 2015 usw.) |
+| 8 | Quartal des Erstellungsjahres |
+| 9–11 | Zähler `001`–`999` |
+
+### Verschlüsselte Datei
+
+Schema: `<IK-Sender>_<IK-Kasse>_<E|T>ASV0<Zähler>`
+
+| Stelle | Inhalt |
+|---|---|
+| 1–10 | IK Sender plus `_` |
+| 11–20 | Abrechnungs-IK Kasse plus `_` |
+| 21 | `E` oder `T` |
+| 22–24 | `ASV` |
+| 25 | `0` |
+| 26–28 | Zähler `001`–`999` |
+
+### Auftragsdatei
+
+Die Auftragsdatei hat denselben Basisnamen wie die verschlüsselte Datei und endet auf `.AUF`.
+
+### Konsistenzregeln
+
+Mindestens folgende Konsistenzregeln sind zu prüfen:
+
+- physischer Dateiname ↔ `UNB_0020`
+- `UNB_0020` ↔ `UNZ_0020`
+- Anzahl Nachrichten in `UNZ_0010` ↔ tatsächliche Anzahl der `UNH`/`UNT`-Paare in der Datei
+- Referenzgleichheit `UNH_0062` ↔ `UNT_0062` je Nachricht
+- physischer Dateiname ↔ KKS-`DATEINAME`
+- Zähler im Dateinamen ↔ KKS-`TRANSFER_NUMMER`
+- Echtdaten-/Testdaten-Kennzeichen zwischen Dateiname, KKS und `UNB 0035`, soweit die jeweilige Schicht vorhanden ist; insbesondere darf `UNB 0035 = 1` nur für Testübertragungen verwendet werden, während Echtdaten dort keinen Testindikator tragen
+
+### Übermittlungszähler
+
+Für Version 1 gilt:
+
+- der Zähler wird auf **Wertebereich `001`–`999`** und **Struktur** (3-stellig, numerisch) geprüft
+- gemäß Spezifikation gilt ein Überlauf nach `999` zurück auf `001`; pro Erstellquartal sind maximal 999 Dateien pro Datensender und Krankenkasse zulässig
+- eine echte quartalsübergreifende Folgesequenzprüfung (lückenlose Inkrementierung über mehrere Übermittlungen hinweg) ist ohne Verlauf **nicht** möglich
+- diese Grenze ist als bewusste V1-Einschränkung im Bericht zu kennzeichnen
+
+## Paarigkeit von Dateien
+
+Zur verschlüsselten Nutzdatendatei gehört **deterministisch genau eine Auftragsdatei** mit identischem Basisnamen plus Endung `.AUF` im selben Verzeichnis.
+
+Version 1 sucht diese Partnerdatei **nicht heuristisch**, sondern unter dem exakt abgeleiteten Pfad.
+
+Wenn die Partnerdatei:
+
+- fehlt oder
+- inhaltlich nicht zur Hauptdatei passt,
+
+wird die übergebene Datei trotzdem geprüft. Zusätzlich wird eine **Warnung** ausgegeben.
+
+## Verarbeitungsmodell und Schichten
+
+Version 1 verwendet bewusst ein **mehrschichtiges internes Modell**.
+
+Mindestens folgende Sichten sind getrennt zu halten:
+
+1. **äußeres Artefakt**
+   - Datei auf Dateisystemebene
+   - Dateiname
+   - Dateityp
+   - PKCS#7-/Auftragsdatei-/Nutzdatei-Schicht
+
+2. **technische Struktur**
+   - Service-Segmente (`UNA`, `UNB`, `UNH`, `UNT`, `UNZ`)
+   - technische Datensätze des KKS-Auftragssatzes
+   - Datei-/Transportebene
+   - Nachrichtenhüllen
+
+3. **kanonisches Fachmodell**
+   - fachlich-technische Repräsentation der ASV-Nachrichten
+   - `ASVREC`, `ASVFEH` und Storno-Ausprägungen
+
+Diese Schichttrennung ist für Version 1 wichtig, damit:
+
+- technische Befunde nicht mit fachlichen Befunden vermischt werden
+- Teilinformationen auch bei Fehlern erhalten bleiben
+- eine spätere GUI differenziert auf dieselben Daten zugreifen kann
+- Spec-Verdikt und zusätzliche Diagnose sauber getrennt bleiben
+
+## Kanonisches internes Modell
+
+Alle unterstützten Eingabearten sollen nach Möglichkeit auf ein **gemeinsames internes Zielmodell** hinauslaufen.
+
+Dieses Modell dient als zentrale Grundlage für:
+
+- technische und fachliche Validierung
+- Berichtserzeugung
+- spätere GUI-Darstellung
+- spätere Erweiterungen wie alternative Ausgabeformen
+
+Zusätzlich muss das Modell **Traceability-Informationen** mitführen, insbesondere:
+
+- Artefaktschicht
+- Prüfstufe
+- Segmenttyp
+- Segmentindex
+- Feld bzw. Feld-ID
+- Rohwert
+- Position
+- Nachricht bzw. Fall
+
+## Mapping auf die Prüfstufen der Spezifikation
+
+Die Spezifikation definiert in Abschnitt 6 fünf Prüfstufen. Version 1 bildet diese **nicht vollumfänglich**, sondern **teilweise und transparent** ab.
+
+| Stufe | Inhalt laut Spec | Umsetzung in V1 |
+|---|---|---|
+| **0** | physikalische Lesbarkeit, Entschlüsselbarkeit | **lokal umsetzbar**, soweit anhand der vorliegenden Datei und des bereitgestellten Materials entscheidbar |
+| **1** | Service-Segment-Struktur, Dateistruktur, Kommunikationspartner, Referenzgleichheiten | **teilweise**: Struktur- und Konsistenzprüfungen werden lokal umgesetzt; **Kommunikationspartnerprüfung** ist ohne Referenzbestände nicht vollständig möglich |
+| **2** | Syntax der Nachricht und Feldebene | **lokal weitgehend** für Typ, Länge, Vorkommen und Segmentreihenfolge gemäß Nachrichtenaufbaudiagramm; gemeint sind **referenzfreie Syntaxregeln** der Nachricht und Feldebene |
+| **3** | formale Feldinhalte und Schlüsselverzeichnisabgleiche | **teilweise**: nur formale Prüfungen ohne externe oder eingebettete Referenzbestände |
+| **4** | Fachverfahren der einzelnen Krankenkassen | **nicht Bestandteil von V1** |
+
+Wichtig:
+
+- V1 darf zusätzlich zu einer spec-konformen Ablehnungsentscheidung **diagnostisch weiter analysieren**, wenn dies technisch sinnvoll ist.
+- Das interne Ergebnis muss deshalb zwischen **Spec-Urteil** und **zusätzlicher diagnostischer Weiteranalyse** unterscheiden.
+- Eine diagnostische Weiteranalyse hebt eine Spec-konforme Ablehnung **nicht** auf.
+- Diagnosebefunde dürfen das Spec-Urteil **niemals** in ein erfolgreiches Prüfurteil umdeuten.
+
+## Parsing und Validierung
+
+### Grundsatz
+
+Parsing und Validierung sind **architektonisch getrennt**, aber nicht künstlich isoliert.
+
+Es gilt ein **Hybrid-Modell**:
+
+- parse-nahe Sofortprüfungen sind erlaubt und sinnvoll
+- eigentliche Regelvalidierung erfolgt getrennt auf dem internen Modell
+
+### Parse-nahe Prüfungen
+
+Bereits beim Einlesen bzw. Parsing dürfen und sollen unter anderem erkannt werden:
+
+- Lesbarkeit und technische Verarbeitbarkeit
+- Zeichensatz- und Trennzeichenprobleme
+- Schicht- und Strukturprobleme
+- Service-Segment-Reihenfolge
+- grobe Segment- und Feldprobleme
+- elementare Formatverletzungen
+- technische Unstimmigkeiten, die für die weitere Verarbeitung relevant sind
+
+Parse-nahe Sofortprüfungen erzeugen **ausschließlich** strukturelle und technische Befunde, etwa zu Lesbarkeit, Zeichensatz, Trennzeichen, Service-Segment-Reihenfolge und groben Segment-/Feldfehlern. **Fachliche Regeln, feldwertbezogene Plausibilitäten und Bezugskontrollen** dürfen nicht in den Parser wandern, sondern gehören in die Regelvalidierung auf dem internen Modell.
+
+### Regelvalidierung
+
+Die eigentliche Validierung auf dem internen Modell umfasst unter anderem:
+
+- Pflichtfeldbeziehungen
+- Struktur- und Konsistenzregeln
+- Summen- und Bezugskontrollen
+- stornospezifische Regeln
+- Regeln für `ASVREC` und `ASVFEH`
+- KKS-Regeln des Auftragssatzes
+- fachlich-technische Plausibilitätsprüfungen, soweit ohne externe Referenzbestände möglich
+- Regeln, die sich aus Hinweisen und Bemerkungen der Spezifikation ergeben
+
+## KKS-Auftragssatz als eigener Prüfgegenstand
+
+AUF-Dateien dürfen architektonisch **nicht nur** als Partnerartefakt betrachtet werden. Der **KKS-Auftragssatz** ist ein **eigenständiger Validierungsgegenstand**.
+
+Mindestens folgende Regeln sind verbindlich zu modellieren:
+
+- **alle Muss-Felder des KKS-Auftragssatzes** werden mindestens auf **Mussbelegung, Feldtyp, Feldlänge und formale Werte** geprüft, auch wenn nicht jedes Feld zusätzlich fachlich gecrosst werden kann
+- `IDENTIFIKATOR = 500000`
+- `VERSION = 01`
+- `LÄNGE_AUFTRAG = 00000348`
+- `SEQUENZ_NR = 000`
+- **keine Teillieferungen** zulässig
+- `VERFAHREN_KENNUNG`: Stelle 20 `E` oder `T`, Stellen 21–23 `ASV`, Stelle 24 `0`
+- `VERFAHREN_KENNUNG_SPEZIFIKATION` ist gemäß Spezifikation ein **Kann-Feld**. Wird das Feld geliefert, muss es einen der definierten Werte tragen, in der Regel `ASVA0` für Abrechnung oder `ASVF0` für Fehlermeldung. Ein nicht geliefertes oder mit Blanks (`HEX 20`) gefülltes Feld ist **kein** Befund.
+- `ABSENDER_EIGNER`, `ABSENDER_PHYSIKALISCH`, `EMPFÄNGER_NUTZER` und `EMPFÄNGER_PHYSIKALISCH` sind als Muss-Felder strukturell und formal zu prüfen; eine vollständige inhaltliche Kommunikationspartnerprüfung ist ohne Referenzbestände jedoch nicht möglich
+- `FEHLER_NUMMER = 000000`
+- `FEHLER_MASSNAHME = 000000`
+- `DATEIVERSION = 000000`
+- `KORREKTUR = 0`
+- `DATEINAME` entspricht dem unverschlüsselten Dateinamen gemäß Dateinamensregeln
+- `DATUM_ERSTELLUNG` ist formal im vorgegebenen 14-stelligen Zahlenformat zu prüfen
+- `DATEIGRÖSSE_NUTZDATEN` (Stellen 179–190, M): muss exakt der unverschlüsselten Nutzdatendateigröße in Bytes entsprechen, soweit die unverschlüsselte Schicht lokal vorliegt.
+- `DATEIGRÖSSE_ÜBERTRAGUNG` (Stellen 191–202, M): muss exakt der verschlüsselten Übertragungsdateigröße in Bytes entsprechen.
+- `ZEICHENSATZ` (Stellen 203–204, M): Festwert `I5` (ISO 8859-15). Abweichungen sind als Fehler zu melden und sind zugleich der formale Anker für die ISO-8859-15-Annahme der gesamten Anwendung.
+- `KOMPRIMIERUNG = 00` (unkomprimiert)
+- `VERSCHLÜSSELUNGSART = 03`
+- `ELEKTRONISCHE_UNTERSCHRIFT = 03`
+- Datumsfelder sind, soweit lokal prüfbar, formal zu validieren
+- Kann-Felder des KKS-Auftragssatzes werden mindestens strukturell auf Feldtyp, Feldlänge und korrekte Nichtbelegungsfüllung geprüft
+
+Zusätzlich gilt für Kann-Felder:
+
+- numerische Kann-Felder werden bei Nichtbelegung mit Nullen (`HEX 30`) gefüllt
+- alphanumerische Kann-Felder werden bei Nichtbelegung mit Blanks (`HEX 20`) gefüllt
+
+## Regeln für Nutzdatennachrichten
+
+### `ASVREC`
+
+Für `ASVREC` sind mindestens zu modellieren:
+
+- Struktur und Reihenfolge der Segmente gemäß Spezifikation
+- Muss-/Kann-Logik je Feld
+- Bezugskonsistenz zwischen `IFA`, `DGN`, `LEA`, `SAC`, `GEN`, `OPA`, `REA`, `IVA`
+- Summenprüfung `REA` gegen `LEA` und `SAC`, soweit ohne externe Bestände lokal möglich
+- Regeln zur Storno-Variante
+- Ein-Datei-eine-Kasse-Regel
+
+### Storno-Variante
+
+Storno ist **keine freie Sonderbehandlung**, sondern eine eigene, klar definierte Strukturvariante.
+
+Für Version 1 gilt:
+
+- bei Storno werden nur die in der Spezifikation vorgesehenen Muss-Segmente und Muss-Felder erwartet
+- `REA` enthält das Rechnungskennzeichen für Storno
+- der Rechnungsbetrag ist gemäß Spezifikation zu behandeln
+- die ursprüngliche Rechnungsnummer ist als Bezug zur stornierten Nachricht zu führen
+- Segmente, die bei Storno laut Spezifikation entfallen, dürfen nicht fälschlich als Muss-Segmente eingefordert werden
+
+### `ASVFEH`
+
+Die Validierung von `ASVFEH` ist von `ASVREC` getrennt zu modellieren. Dabei gilt:
+
+- `ASVFEH` kann gemäß Spezifikation in zwei strukturellen Ausprägungen auftreten:
+  - als **eigenständige Übertragungsdatei** mit ausschließlich `ASVFEH`-Nachricht(en) – typisch für Stufe-1-Rückmeldungen (Struktur: `UNB`, `UNH` mit Nachrichtentyp `ASVFEH`, `FHL`, `UNT`, `UNZ`).
+  - als **eingebettete Nachricht** innerhalb einer Übertragungsdatei, die zusätzlich die Originalnutzdatensegmente trägt – typisch für Stufen 2 bis 4 (Struktur: `UNH`, originale Nutzdatensegmente, `FHL`, `UNT`).
+  V1 muss beide Ausprägungen erkennen und korrekt verarbeiten.
+
+- Die Originalnachricht ist bei **Prüfstufe 1 nicht zu übertragen**.
+- Die Originalnachricht ist bei **Prüfstufen 2 bis 4 grundsätzlich mitzuliefern**. Ihre Abwesenheit ist **kein Fehler**, wenn die Originalnutzdaten gemäß Spezifikation nicht lesbar oder nicht der vereinbarten Syntax entsprechend übertragbar waren. V1 darf das Fehlen der Originalnachricht in `ASVFEH` daher nicht pauschal als Befund melden, sondern höchstens als Hinweis.
+- Die Validierung einer `ASVFEH` **erstreckt sich nicht auf die mitgelieferte Originalnachricht** als eigenständigen Validierungsgegenstand.
+- Hinweis: Die Spec verbietet, eine Fehlernachricht ihrerseits mit einer Fehlernachricht zu beantworten. Diese Regel betrifft das Verfahren zwischen Sender und Empfänger und ist an einer einzelnen, isoliert übergebenen Datei nicht prüfbar. V1 setzt sie deshalb **nicht** als Validierungsregel um.
+- Für `FHL`-Segmente gilt: Kann-Datenelemente werden zu Muss-Datenelementen, wenn ihr Inhalt aus der Fehlersituation bestimmbar ist. V1 darf dies nur dort als Fehler umsetzen, wo diese Ermittelbarkeit aus der vorliegenden Datei belastbar ableitbar ist.
+- Die Spezifikation sieht für `FHL` bis zu 99 Vorkommen vor; diese Obergrenze ist strukturell zu berücksichtigen.
+
+## Bekannte Spec-Fallstricke und Pflichtregeln
+
+Die folgenden Regeln sind verbindlich zu berücksichtigen. **Die hier genannten Sonderwerte und Ausnahmen dürfen im jeweils von der Spec vorgesehenen Feld- und Kontextbezug nicht als Fehler oder Warnung gemeldet werden** — eine naive Format- oder Pflichtfeldprüfung muss diese Sonderfälle aktiv aussparen:
+
+- **Geburtsdatum im Ersatzverfahren** (Feld `8/8.4.3`): Im Format `JJJJMMTT` sind beliebige numerische Werte zulässig; der Inhalt muss nicht zwingend einem logischen Kalenderdatum entsprechen. Zusätzlich sind die Platzhalter `00` (unbekannter Tag), `0000` (unbekannter Tag und Monat) und `00000000` (vollständig unbekannt) zulässig. Eine Datumsplausibilisierung in diesem Feld ist daher unzulässig.
+- **Pseudo-GOP `88999`** bzw. regionale Pseudo-GOP ist für Sachkosten ohne Sachzusammenhang zulässig.
+- **GOÄ-Übermittlung**: In Feld `3/3.2.1` ist die Pseudo-GOP zu übertragen, in Feld `3/3.2.5` die zugehörige GOÄ-Ziffer.
+- **Vertretung**: Bei Teamebene `4` ist die Teamebene des Vertretenen maßgeblich.
+- **Obsolete Muss-Felder `4/4.2.4` und `4/4.2.5`** (ab Q1/2020 fachlich obsolet) bleiben füllpflichtig mit beliebigem Inhalt, der jedoch **nicht ausschließlich aus Leerzeichen** bestehen darf. Inhaltlich werden diese Felder nicht geprüft.
+- **Negative numerische Werte** zählen das führende Minuszeichen nicht zur maximalen Feldlänge.
+- **Dezimalzeichen `,`** zählt nicht zur maximalen Feldlänge.
+- **Pro Datei darf nicht kassenübergreifend gebündelt werden**.
+- **Sortierreihenfolge der Nachrichten** innerhalb einer Datei ist gemäß Spec willkürlich. V1 darf keine Sortierregel erzwingen.
+- **Vertraglich bedingte Muss-Felder**: Einige Muss-Felder sind in der Spec mit dem Hinweis „wird erst geliefert, wenn vertraglich vereinbart" markiert. Diese werden in V1 nicht hart erzwungen.
+
+### Versichertennummer
+
+Für Version 1 gilt mindestens die Strukturprüfung:
+
+- Stelle 1: Alpha `A`–`Z` ohne Umlaute
+- Stellen 2–9: numerisch
+- Stelle 10: Prüfzifferstelle vorhanden
+
+Eine echte algorithmische Prüfziffervalidierung darf nur dann verpflichtend werden, wenn der offizielle Algorithmus außerhalb der ASV-Spezifikation eindeutig, verlässlich und rechtssicher vorliegt. Sie ist **kein Muss dieses Dokuments**, solange die ASV-Spezifikation selbst den Algorithmus nicht definiert.
+
+## Regelmodell und Design Patterns
+
+Prüfregeln sind in Version 1 **explizit als eigene, separat testbare Regel-Komponenten** zu modellieren.
+
+Erwartet wird ein regelorientierter Zuschnitt, zum Beispiel mit sinnvollen Pattern-Ansätzen wie:
+
+- Strategy / Policy für Prüfvarianten
+- Specification-artigen Regelobjekten für kombinierbare Regeln
+- Pipeline / Chain für geordnete Prüfschritte
+
+Die Regeln dürfen **nicht verteilt und unübersichtlich** in Parsern, Hilfsklassen oder Services zerfasern.
+
+## Fehlertoleranz und Robustheit
+
+Version 1 verfolgt ein robustes Leitprinzip:
+
+> Die Datei wird auf Biegen und Brechen geprüft, so weit die Technik das zulässt.
+
+Daraus folgen insbesondere:
+
+- bei Teilfehlern wird nach Möglichkeit weitergearbeitet
+- ein schwerer Fehler in einer Nachricht stoppt nicht automatisch die übrigen Nachrichten derselben Datei
+- frühe technische Probleme verhindern nicht grundsätzlich einen Bericht
+- Teilbefunde werden erhalten und sichtbar gemacht
+- zusätzliche diagnostische Analyse ist erlaubt, auch wenn die Spec auf derselben Ebene bereits eine Zurückweisung verlangen würde
+
+Wichtig: Die diagnostische Weiteranalyse ändert **nicht** das spec-konforme Prüfurteil.
+
+## Unbekannte oder fremde Inhalte
+
+Unbekannte, nicht erwartete oder versionsfremde Segmente bzw. Felder sollen, soweit technisch möglich:
+
+- **erhalten** bleiben
+- als **unbekannt** markiert werden
+- in Bericht und internem Modell sichtbar sein
+- nicht vorschnell verworfen werden
+
+Das Ziel ist maximaler Erkenntnisgewinn aus der Eingabedatei, auch wenn nicht alles vollständig interpretierbar ist. Das Erhalten unbekannter Inhalte dient ausschließlich der **Diagnose** und verändert das **Spec-Urteil** nicht.
+
+## Ergebnis- und Befundmodell
+
+### Interne Ergebnisstruktur
+
+Der Kern liefert **immer ein strukturiertes internes Resultat**. Dieses Resultat ist die einzige Grundlage für:
+
+- Konsolenbericht
+- Berichtdatei
+- spätere GUI-Darstellung
+
+Der Kern selbst erzeugt keine textnahen Endformate.
+
+### Befundarten
+
+Das Befundmodell kennt:
+
+- **Fehler**
+- **Warnungen**
+- **Hinweise**
+
+Zusätzlich muss jeder Befund mindestens folgende Meta-Informationen tragen, soweit sinnvoll ermittelbar:
+
+- Artefaktschicht
+- Prüfstufe
+- Prüfebene / Prüfbereich
+- Segmenttyp
+- Segmentindex
+- Feld / Feld-ID
+- Rohwert
+- Position
+- Nachricht bzw. Fall
+- optional offizieller Spec-Fehlercode
+
+Wo eine eindeutige Zuordnung zu einem offiziellen Fehlercode möglich ist, wird dieser am Befund hinterlegt. Wo keine eindeutige Zuordnung möglich ist, darf das interne Modell eigene technische Befundklassen verwenden.
+
+**Vorrang offizieller Fehlercodes**: Die Spezifikation definiert in Abschnitt 7 generische Sammelfehlercodes (`xx999`, `3A998`, `4A998`). Diese dürfen **nicht** verwendet werden, wenn für den konkreten Sachverhalt ein spezifischerer offizieller Fehlercode existiert. V1 hält diese Vorrangregel ein, sobald Befunde mit offiziellen Fehlercodes annotiert werden.
+
+### Gültigkeitsentscheidung und Exit-Codes
+
+Nur **Fehler** machen eine Datei insgesamt ungültig.
+
+| Exit-Code | Bedeutung |
+|---|---|
+| `0` | gültig, keine Fehler-Befunde |
+| `1` | ungültig, mindestens ein Fehler-Befund |
+| `2` | Bedienfehler, zum Beispiel fehlendes Argument oder nicht lesbare Eingabedatei |
+
+Warnungen und Hinweise beeinflussen den Exit-Code nicht.
+
+Auch bei `Exit-Code 2` soll, soweit technisch möglich, ein **Minimalbericht** erzeugt werden, der den Bedien- oder Zugriffsfehler nachvollziehbar beschreibt.
+
+## Prüfebenen und Berichtsgliederung
+
+Die Anwendung soll Befunde mindestens auf zwei Ebenen explizit unterscheiden:
+
+1. **Datei-/Transportebene**
+   - Dateiname
+   - äußere Schichten
+   - Partnerdatei-Aspekte
+   - technische Hüllen
+   - Gesamtstruktur
+
+2. **Nachrichten-/Fall-Ebene**
+   - einzelne `UNH`…`UNT`-Nachrichten
+   - fallbezogene Inhalte und Befunde
+
+Der Standardbericht ist **hierarchisch** aufgebaut, primär nach:
+
+- Datei
+- Schichten
+- Nachrichten/Fällen
+- Befunden
+
+Zusätzlich soll der Standardbericht strukturierte Bestandsinformationen enthalten, zum Beispiel:
+
+- erkannter Dateityp
+- erkannte Schichten
+- Anzahl Nachrichten/Fälle
+- relevante Kopfdaten
+- Übermittlungszähler
+- spec-konformes Prüfurteil
+- zusätzliche diagnostische Auffälligkeiten
+
+## Grenzen der Validierung in Version 1
+
+Version 1 enthält **keine eingebetteten Katalog- oder Referenzbestände**.
+
+Das bedeutet insbesondere:
+
+- keine mit der Anwendung ausgelieferten ICD-/OPS-/IK-/Stammdatenbestände
+- keine Abhängigkeit von externen Online-Diensten
+- keine lokal separat gepflegten Referenzdaten als Voraussetzung
+
+Konsequenzen:
+
+- Kommunikationspartnerprüfungen können nicht vollständig umgesetzt werden.
+- Schlüsselverzeichnisabgleiche für IK, ICD, OPS und ähnliche Bestände entfallen.
+- Die in der Spezifikation geforderte Prüfung der BSNR gegen das ASV-Verzeichnis bzw. die Arztstammdaten ist mangels Referenzbestand **nicht Bestandteil von V1**; eine BSNR wird strukturell, aber nicht inhaltlich gegen einen Stammdatenbestand geprüft.
+- Stufe 3 ist in Version 1 deshalb **nur formal**, nicht vollständig.
+- Stufe 4 ist nicht Bestandteil von Version 1.
+
+Prüfungen, die ohne solche Bestände nicht belastbar entscheidbar sind, werden in Version 1 **nicht durchgeführt**. Sie dürfen aber als **bewusst nicht geprüfter Bereich** im Bericht kenntlich gemacht werden.
+
+## Krypto- und Schichtverarbeitung
+
+Version 1 unterstützt Basis- und Tiefenprüfung verschlüsselter bzw. transportnaher Dateien im Scope der Anwendung.
+
+### Architektur
+
+- Krypto-Verarbeitung erfolgt **innerhalb der Java-Anwendung**.
+- Externe Tools oder Binaries sind ausgeschlossen.
+- Technische Krypto-Integration ist gekapselt hinter internen Ports und Abstraktionen.
+- Wenn die äußere Schicht erfolgreich verarbeitet werden kann, wird automatisch bis zur **inneren fachlichen Nutzlast** weitergegangen und diese mitvalidiert.
+- Wenn bereitgestelltes Krypto-Material technisch nicht nutzbar ist, erfolgt **Fallback auf Basisprüfung** mit Warnung.
+- Schlüssel- und Passwortmaterial wird nur **explizit per CLI** bereitgestellt.
+- Für Version 1 darf der Materialinput pragmatisch auf wenige Formate begrenzt werden, solange dies dokumentiert und technisch sauber gekapselt ist.
+
+### Mindest-Algorithmen
+
+Soweit die jeweilige Datei diese Informationen oder Anforderungen betrifft, sind mindestens folgende Verfahren zu berücksichtigen:
+
+| Aspekt | Verfahren |
+|---|---|
+| Verschlüsselungsformat | PKCS#7 |
+| Session Key | AES-256-CBC |
+| Interchange Key | RSA 4096 Bit |
+| Hash-/Signaturverfahren | SHA256withRSAandMGF1 / PSS |
+| RSA-Exponent | Fermat-4 (`2^16 + 1`) |
+
+Nicht-PSS-Altverfahren vor der Umstellung müssen in Version 1 **nicht** aktiv unterstützt werden, dürfen aber als erkannte Abweichung gemeldet werden.
+
+## CLI-Zuschnitt in Version 1
+
+Version 1 bleibt bewusst minimal.
+
+### CLI-Grundsätze
+
+- genau **ein fachlicher Hauptmodus**: validieren
+- keine frühe Aufblähung durch zusätzliche Subcommands
+- keine Pflicht für `--help` oder `--version`
+- README ist die primäre Nutzungsdokumentation
+- CLI-Optionsnamen sind **Englisch**
+- nutzerseitige Ausgaben sind **Deutsch**
+- Schlüssel- und Passwortmaterial für PKCS#7-Verarbeitung wird ausschließlich **explizit per CLI-Option** übergeben. Ohne Material erfolgt **Fallback auf Basisprüfung mit Warnung** statt hartem Abbruch. Konkrete Optionsnamen sind in der README dokumentiert.
+
+### Ausgabewege
+
+- strukturierter Validierungsbericht in **Konsole**
+- derselbe Bericht zusätzlich in **Berichtdatei**
+- technisches Logging zusätzlich in **Log-Datei**
+
+## Logging und Berichtserzeugung
+
+### Logging
+
+Version 1 verwendet für technisches Logging:
+
+- **SLF4J als Fassade**
+- **Log4j2 als Implementierungs-Bindung**
+
+Die konkrete Log4j2-Bindung darf ausschließlich in Bootstrap und Logging-Adapter sichtbar sein.
+
+Das Logging ist **immer aktiv** und wird in eine **Log-Datei** geschrieben.
+
+### Bericht
+
+Der Validierungsbericht ist **kein normales Logging**, sondern ein eigenes Ausgabeartefakt mit stabiler Struktur.
+
+Er wird:
+
+- in die **Konsole** geschrieben
+- in eine **Berichtdatei** geschrieben
+
+Bericht und Logging sind architektonisch strikt getrennt.
+
+## Sprach- und Dokumentationskonventionen
+
+Für Version 1 gelten folgende Konventionen:
+
+- Nutzertexte auf **Deutsch**
+- JavaDoc auf **Deutsch**
+- Logtexte auf **Deutsch**
+- Berichtstexte auf **Deutsch**
+- Klassennamen auf **Englisch**
+- Bezeichner und Variablennamen auf **Englisch**
+
+## Test- und Qualitätsanforderungen
+
+### Teststufen
+
+Verbindlich vorgesehen sind:
+
+- **Unit-Tests**
+- **CLI-Integrationstests**
+- **dateibasierte End-to-End-Tests**
+
+Dabei gilt:
+
+- keine Echtdaten im Projekt
+- nur synthetische, anonymisierte oder speziell erzeugte Testdaten
+- Parser-, KKS-, ASVFEH- und Storno-Fälle sind gezielt mit Testartefakten abzudecken
+
+### Qualitätsgates
+
+Verbindliche Gates für Version 1:
+
+- Build muss grün sein
+- alle Tests müssen grün sein
+- **Coverage mindestens 85 %** gesamtprojektweit
+- **PIT-Mutation-Score mindestens 70 %** gesamtprojektweit
+
+Zusätzlich gelten differenzierte Zielschwellen:
+
+| Bereich | Coverage | Mutation |
+|---|---|---|
+| `domain` | ≥ 95 % | ≥ 85 % |
+| `application` | ≥ 90 % | ≥ 80 % |
+| `adapter.out.*` | ≥ 90 % | ≥ 75 % |
+| `adapter.in.cli` | ≥ 80 % | ≥ 60 % |
+| `bootstrap` | ausgenommen | ausgenommen |
+
+Zusätzlich gilt:
+
+- echte Parser-, Erkennungs- und Validierungslogik soll sehr hoch abgesichert sein
+- triviale Getter/Setter/Record-Accessoren benötigen keine künstlichen Pflicht-Tests
+- einfache unveränderliche Datenträger sollen bevorzugt als **Records** modelliert werden, wenn das fachlich-technisch passt
+- Wertobjekte mit eigenem Validierungsbedarf werden als reguläre Klassen modelliert
+
+## Regeln für spätere Umsetzung durch eine kontextlos arbeitende KI
+
+Für spätere KI-gestützte Umsetzung gilt:
+
+- Architektur strikt evolutionär weiterentwickeln
+- keine große Komplett-Neustrukturierung in einem Wurf
+- Kern von Infrastruktur trennen
+- neue Technik nur über Adapter einführen
+- Regeln explizit und separat testbar schneiden
+- KKS-Auftragssatz und `ASVFEH` als eigene Prüfdomänen behandeln
+- Berichtserzeugung nie im Kern verankern
+- robuste Weiterverarbeitung bevorzugen
+- Spec-Verdikt und Diagnose strikt trennen
+- keine unnötigen Bibliotheken, aber pragmatischer Einsatz sinnvoller Tools ist erlaubt
+- kein Spring, kein Quarkus, kein DI-Framework
+- manuelles Constructor-Wiring im Bootstrap
+- Version 1 bewusst klein halten und zuerst nutzbar machen
+
+## Nicht-Ziele von Version 1
+
+Nicht Ziel von Version 1 sind insbesondere:
+
+- GUI
+- Mehrversionssupport der ASV-Spezifikation
+- Web-, Server- oder Containerbetrieb
+- Verzeichnis- oder Batchverarbeitung
+- JSON-Ausgabe
+- externe Konfigurationsdateien
+- eingebettete oder online aufgelöste Referenzdatenbestände als Pflichtbestandteil
+- vollständige Kommunikationspartnerprüfung ohne Referenzdaten
+- vollständige Stufe-3-Schlüsselverzeichnisabgleiche
+- Stufe-4-Prüfungen
+- automatische Korrektur oder Rewrite von Eingabedateien
+- PDF-Bericht
+- funktionale Aufblähung ohne praktischen Bedarf
+
+## Glossar
+
+| Begriff | Bedeutung |
+|---|---|
+| **ASV** | Ambulante spezialfachärztliche Versorgung gemäß § 116b Abs. 6 Satz 12 SGB V |
+| **ASVREC** | EDIFACT-Nachrichtentyp für die ASV-Abrechnung (Rechnung) |
+| **ASVFEH** | EDIFACT-Nachrichtentyp für die ASV-Fehlerrückmeldung |
+| **Storno** | Spezielle Strukturvariante einer `ASVREC`-Nachricht zur Stornierung einer zuvor übermittelten Rechnung |
+| **KKS** | Kommunikations-Kontroll-Satz; Auftragssatzformat zur Beschreibung einer Übertragungsdatei (Auftragsdatei `.AUF`) |
+| **EDIFACT** | Electronic Data Interchange For Administration, Commerce and Transport – Format der Nutzdatensegmente |
+| **Service-Segmente** | EDIFACT-Hüllsegmente: `UNA`, `UNB`, `UNH`, `UNT`, `UNZ` |
+| **FHL** | Fehlersegment innerhalb einer `ASVFEH`-Nachricht |
+| **PKCS#7** | Standard-Containerformat für signierte und verschlüsselte Nachrichten gemäß ISIS-MTT |
+| **Prüfstufen** | Spec-Prüfstufen 0–4 (physikalisch / Datei und Service-Segmente / Syntax / formale Feldinhalte / Fachverfahren der Krankenkassen) |
+| **Spec-Urteil** | Verbindliches Prüfurteil gemäß Spezifikation: gültig oder ungültig |
+| **Diagnose** | Zusätzliche, spec-unabhängige Weiteranalyse zur Erkenntnisgewinnung; verändert das Spec-Urteil nicht |
+| **Hexagonale Architektur** | Trennung von Domain/Application und technischen Adaptern (Ports & Adapters) |
+
+## Dokumenthistorie
+
+| Version | Wesentliche Änderungen |
+|---|---|
+| v1 | Erstfassung mit Architekturgrundsätzen |
+| v2 | ISO-8859-15, Prüfstufen-Mapping, Dateinamen, Crosschecks, KKS, ASVFEH, Krypto-Mindestalgorithmen, Exit-Code 2, differenzierte Quality Gates |
+| v3 | `VERFAHREN_KENNUNG_SPEZIFIKATION` als Kann-Feld, `DATEIGRÖSSE_*` als Crosschecks, `ZEICHENSATZ = I5`, ASVFEH-Originalnachricht-Ausnahme, Hybrid-Modell geschärft, `UNZ_0010`/`UNH_0062`-Crosschecks, Sortierreihenfolge willkürlich |
+| v4 | Stufe-2-Wording entschärft, Diagnose darf Spec-Urteil nicht aufheben, alle KKS-Muss-Felder strukturell zu prüfen, ABSENDER/EMPFÄNGER-Felder explizit, Sonderfall-Regel kontextbezogen, `UNB 0035`-Testindikator präzisiert, FHL bis 99 Vorkommen, Minimalbericht bei Exit-Code 2 |
+| v5 | Geburtsdatum-Sonderfall vollständig (beliebige numerische Werte plus Platzhalter), GOÄ-Felder konkret (`3/3.2.1`/`3/3.2.5`), obsolete Felder „nicht ausschließlich Leerzeichen", Übermittlungszähler-Wertebereich `001`–`999` mit Wraparound, ASVFEH-Strukturvarianten (eigenständige vs. eingebettete Datei), Vorrang offizieller Fehlercodes (`xx999`/`3A998`/`4A998`), BSNR-Stammdatencheck als nicht-Bestandteil von V1, Glossar, Dokumenthistorie |
+
+## Zusammenfassung
+
+Version 1 des ASV-Format-Validators ist eine bewusst schlanke, lokal unter Windows laufende Java-21-CLI-Anwendung mit hexagonaler Architektur, robustem Validierungskern, explizitem Regelmodell und strikt getrennten Infrastrukturadaptern. Sie prüft genau eine Datei pro Lauf gegen die Technische Anlage ASV 1.09, verarbeitet Eingaben auf Basis von ISO 8859-15, modelliert AUF/KKS, `ASVREC`, `ASVFEH` und Storno explizit, trennt spec-konformes Prüfurteil von zusätzlicher diagnostischer Weiteranalyse, bildet Prüfstufen transparent nur insoweit ab, wie dies lokal ohne Referenzbestände möglich ist, und erzeugt daraus einen stabil gegliederten deutschen Textbericht sowie ein technisches Log.