asv-format-validator/docs/specs/technik-und-architektur.md

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.