---
typ: assessment
status: aktuell
datum: 2026-04-20
version: 1.0
titel: GOÄ-/GOZ Make-or-Buy Assessment
leseform: ausführliches Arbeitsdokument (Basis für die HTML-Kompaktfassung)
---

# GOÄ-/GOZ Make-or-Buy Assessment — Arbeitsdokument

> **Hinweis:** Dieses Dokument ist das ausführliche Arbeitsdokument zur Make-or-Buy-Entscheidung für das GOÄ-/GOZ-Prüfmodul des Beihilfe- und Heilfürsorge-Assistenten (chacha). Die verdichtete HTML-Kompaktfassung liegt als [`GOÄ-GOZ-Assessment.html`](../GOÄ-GOZ-Assessment.html) vor. Beide Dokumente verweisen auf dieselbe Quellenlage (`docs/assessments/sources/sources.jsonl`).
>
> **KI-Hinweis:** Das Dokument wurde unter Einsatz von KI durch Projektbeteiligte ohne formale juristische Qualifikation erstellt und bearbeitet. Die Aussagen sind unverbindlich und setzen eine abschließende juristische Prüfung im öffentlichen Auftraggeberkontext voraus.

## Inhaltsverzeichnis

1. Management Summary
2. Fragestellung und Prüfrahmen
3. Normhierarchie und Prüfrahmen
4. Aktueller Implementierungsstand (Make-Seite)
5. Marktübersicht (Buy-Seite)
6. Feature-Vergleichsmatrix (45 Kriterien)
7. Juristische Dimension
8. Wirtschaftliche Dimension (TCO, drei Szenarien)
9. Strategische Dimension
10. Risiken Make-vs-Buy
11. Entscheidungsmatrix und Empfehlung
12. Anhänge (Datenschutz-Folgenabschätzung Kurzfassung, Abkürzungen, Quellenverzeichnis)

---

## 1. Management Summary

Die Frage, ob das Land Niedersachsen das GOÄ-/GOZ-Prüfmodul des Beihilfe- und Heilfürsorge-Assistenten beim Marktführer beschafft oder weiter in Eigenentwicklung führt, hat juristische, wirtschaftliche und strategische Dimensionen. Die Recherche zeigt drei zentrale Befunde:

**Erstens — Marktlage**: Der deutsche Beihilfe-Markt wird im GOÄ-/GOZ-Prüfsegment durch **ZABAS®** (Hersteller Global Side, heute Teil der msg insurance suite, Vertrieb für Beihilfestellen über die AKDB-Tochter **Beihilfe-Service GmbH** unter dem Produktnamen **ZABAS BeiPro**) dominiert. Die Kooperation Bayern–Sachsen–Thüringen hat 2024 einen Rahmenvertrag mit geschätztem Auftragswert von **6.149.564,15 EUR netto** über 4 Jahre (plus zweimal ein Jahr Verlängerungsoption) im Verhandlungsverfahren ohne Aufruf zum Wettbewerb geschlossen (Quelle src-003).

**Zweitens — Reifegrad der Eigenentwicklung (chacha)**: Das Modul `goaegoz-tool` ist als **implementierter** FastAPI-Dienst mit geladenen Referenzdaten und Prüfpipeline im Repository vorhanden, mit 2.843 GOÄ-Ziffern, 215 GOZ-Ziffern, 13 GOÄ-Ausschlusspaaren, 27 Häufigkeitsregeln, 9 Grundleistungs-Abhängigkeiten, LLM-gestützter Qualitätsprüfung der §5-Abs.-2-Begründungen und SQLite-History-Store für die mehrperiodische Doppeleinreichungserkennung. Offene Baustellen: fehlende Unit-Tests im Tool-Paket, keine Integration von BEMA-Z (34) und E-GO (40) trotz vorhandener Daten, GOÄneu Stufe 0 (Schema-Stub).

**Drittens — Recht**: Die entscheidungsrelevante europarechtliche Einordnung stützt sich auf **Anhang III Nummer 5 Buchstabe a** der EU-KI-Verordnung (KI zur Beurteilung von Ansprüchen auf grundlegende öffentliche Unterstützungsleistungen = Hochrisiko). Daraus ergeben sich für beide Pfade (Make und Buy) identische Anforderungen an menschliche Aufsicht, Protokollierung und Erklärbarkeit. Der Unterschied liegt in der **Nachweisfähigkeit**: Eigenentwicklung kann Prüfregel-Offenlegung und deterministische Nachvollziehbarkeit belegen, eine Drittanbieter-Blackbox nicht ohne vertragliche Zusicherungen.

**Empfehlung (vorläufig)**: Szenario **C — Eigenentwicklung fortsetzen und um HFB-/BEMA-Z-/GOÄneu-Dimension erweitern**. Die Entscheidung trägt auf drei Gründen:

1. **Die NLBV-Anforderung umfasst Beihilfe _und_ Heilfürsorge** (NBG §§224/224a, Runderlass). Kein Marktprodukt bildet die Heilfürsorge spezifisch ab; ZABAS BeiPro ist ein reines Beihilfe-Produkt, MediCheck/EASYGOÄ adressieren ausschließlich Leistungserbringer oder PKV-Versicherte.
2. **Die Kostenposition**: Die Bayerische Vergabe (6,15 Mio EUR / 4 Jahre) ist der einzige belastbare öffentliche Referenzwert. Auf Niedersachsen extrapoliert (proportional zu Beihilfeberechtigten) liegt die Buy-Erwartung über 5 Jahre bei 5–9 Mio EUR. Die bisher kumulierten Eigenentwicklungskosten des `goaegoz-tool` und der umgebenden chacha-Architektur liegen unterhalb dieses Bereichs und erzeugen Eigentum an Code, Regeln und Daten — nicht Abhängigkeit.
3. **Die GOÄneu-Reform 2027** (rund 5.500 neue Gebührennummern, Wegfall der Steigerungsfaktoren) ist für jeden Anbieter ein Umschaltschnitt. Wer die Umschaltung selbst im Repository versioniert, spart die marktübliche Neulizenzierung der alten GOÄ plus GOÄneu.

Die Empfehlung ist **nicht**: „kein Fremdsystem kaufen". Sie ist: „den GOÄ-/GOZ-Prüfkern als Eigenentwicklung behalten, weil er an die chacha-DSL-Regelkette und an die Heilfürsorge-Architektur gebunden ist; Teilmodule (Vision-OCR, Datenhaltung) bleiben modular austauschbar und können eingekauft werden, wo das günstiger ist." Die Entscheidungsmatrix in Abschnitt 11 operationalisiert diese Abwägung.

---

## 2. Fragestellung und Prüfrahmen

### 2.1 Auftrag

Das Niedersächsische Landesamt für Bezüge und Versorgung (NLBV) führt das eBeihilfe-Verfahren (NBhVO) und die Heilfürsorge-Bearbeitung (NBG §§224/224a mit den Heilfürsorgebestimmungen durch Runderlass). In beiden Pfaden sind Arztrechnungen nach GOÄ und GOZ auf formelle Korrektheit, Plausibilität der Steigerungsfaktoren (§5 Abs. 2 GOÄ / GOZ), Kombinationsverbote, Häufigkeitsregeln und Doppeleinreichungen zu prüfen. Das GOÄ-/GOZ-Prüfmodul ist dabei ein Baustein in der durchgängigen Antragsverarbeitung — nicht der gesamte Antragsworkflow.

Die zu entscheidende Frage lautet:

> Soll das Land Niedersachsen das GOÄ-/GOZ-Prüfmodul als Drittanbieter-Produkt beschaffen oder die bereits begonnene Eigenentwicklung (chacha / `goaegoz-tool`) fortsetzen?

### 2.2 Abgrenzung

**In Scope**: Der deterministische Prüfkern für GOÄ/GOZ-Positionen (Ziffern, Faktoren, Kombinationen, Häufigkeiten, Orphan-Addons), die LLM-gestützte Begründungsanalyse nach §5 Abs. 2, die periodenübergreifende Duplikaterkennung sowie die Integration der Prüfergebnisse in den Beihilfe-Workflow (Übergabe an samba als System of Record).

**Out of Scope**: Das gesamte Beihilfe-Fachverfahren (Antragserfassung, Bescheidversand, Bemessungssatz-Logik, Eigenbehalte-Berechnung) bleibt unabhängig; dort ist samba das System of Record und die Drittanbieter-Landschaft ist etabliert. Die Make-or-Buy-Frage für das Fachverfahren selbst ist nicht Gegenstand dieses Assessments.

### 2.3 Prüfmaßstab

Die Entscheidung wird anhand von fünf Dimensionen geprüft:

| Dimension | Kernfrage | Gewicht (Vorschlag) |
|---|---|---|
| Fachliche Abdeckung | Deckt die Lösung Beihilfe _und_ Heilfürsorge ab? Wie ist die Regelbasis gepflegt? | 25 % |
| Rechtskonformität | EU AI Act, DSGVO, §203 StGB, VwVfG §35a — welche Risiken tragen die Pfade? | 25 % |
| Wirtschaftlichkeit | TCO über 5 Jahre; Exit-Kosten; Pflegeaufwand | 20 % |
| Strategie & Daten-Hoheit | GOÄneu-Readiness; Integration in samba; Datenflüsse | 20 % |
| Reifegrad & Risiko | Produktreife, dokumentierte Lücken, Pflegegarantie | 10 % |

---

## 3. Normhierarchie und Prüfrahmen

Die rechtliche Grundlagenbewertung liegt bereits mit der [`gesetzeshierarchie-beihilfe-assistent.html`](../gesetzeshierarchie-beihilfe-assistent.html) und der Kompaktfassung [`beihilfe-assistent-rechtskonformitaet-v3.html`](../beihilfe-assistent-rechtskonformitaet-v3.html) vor. Für die Make-or-Buy-Betrachtung sind folgende Normen einschlägig und werden in Abschnitt 7 vertieft:

| Ebene | Norm | Wirkung auf Make/Buy |
|---|---|---|
| EU-Recht | Verordnung (EU) 2024/1689 — KI-Verordnung (EU AI Act), Art. 14, Anhang III Nummer 5 Buchstabe a | Hochrisiko-Einordnung greift in beiden Pfaden; Buy zieht Dienstleister in Betreiber-Kette ein |
| EU-Recht | DSGVO Art. 9 Abs. 2 lit. b (primär); lit. g und lit. h (alternativ im Behörden- bzw. Gesundheitskontext); Art. 22, Art. 28 (AVV), Art. 32 (technische und organisatorische Maßnahmen, TOM), Art. 35 (DSFA), Art. 44 ff. (Drittlandsübermittlung) | Buy erfordert AVV, ggf. TIA; Make bleibt Eigenverarbeitung durch das Land; die Wahl der tragenden Art.-9-Ziffer ist im Rahmen der DSFA festzulegen |
| Bundesrecht | VwVfG §35a i. V. m. NVwVfG §1 | Rechtsvorschrift als Öffnungsklausel gilt unabhängig vom Hersteller |
| Bundesrecht | §203 StGB (Fassung seit 2017): Abs. 2 (Amtsträgerinnen und Amtsträger der Beihilfestelle als Grundnorm) und Abs. 3/4 (mitwirkende Personen) | Make und Buy: Amtsträgerpflicht nach Abs. 2 gilt in beiden Pfaden unmittelbar; Abs. 3/4 zusätzlich bei Einbindung von Drittanbietern (Buy) — Auswahl-, Verpflichtungs- und Überwachungspflicht |
| Landesrecht | NBG §95 Abs. 4 | _lex specialis_ zu §35a VwVfG; gilt für Beihilfe und Heilfürsorge; voll erfüllende automatisierte Entscheidung |
| Vergaberecht | §§103 ff. GWB, VgV, UVgO; Art. 12 RL 2014/24/EU (In-house), §108 GWB | Buy unterliegt Vergaberecht; Make kann als In-house-Lösung vergaberechtsfrei sein |
| Haftung | Art. 34 GG, §839 BGB | Amtshaftung gegenüber Antragstellenden bleibt beim Land — Rückgriff auf Dienstleister abhängig vom Vertrag |

---

## 4. Aktueller Implementierungsstand (Make-Seite)

> **Open-Loops (OL):** Kurzverweise wie **OL-068 — GOÄneu Schema** verweisen auf Einträge in `docs/open-loops.md`. **Volltexte und Status sind dort maßgeblich**; ausführliche Beschreibungen können bei Bedarf nachgeliefert werden.

### 4.1 Architektur

Das Modul `goaegoz-tool` ist eine eigenständige FastAPI-Anwendung (Port 8009 im Dev; Betrieb über die bestehende Compose-/Proxy-Kette). Es wird in die chacha-Gesamtarchitektur eingebunden (Temporal-Workflows, DSL-Regelkette, BFF für die Sachbearbeiter-Oberfläche) und liefert strukturierte Prüfergebnisse (`CheckReport`) zur Weiterverarbeitung — der **Ist-Code** umfasst dabei bereits Router, Checker, Analyzer und History-Store (siehe Modul-README).

Kernmodule:

- `app/main.py` — FastAPI-Einstieg; Router `check` (Einzelfallprüfung) und `history` (periodenübergreifend)
- `app/services/checker.py` — deterministische Prüfungen (Ziffern, Faktoren, Beträge, Kombinationsverbote, Häufigkeiten, Orphan-Addons)
- `app/services/analyzer.py` — LLM-gestützte Bewertung der §5-Abs.-2-Begründung; Roh-Text-Analyse
- `app/services/llm_client.py` — Anbindung an OpenRouter (`qwen/qwen2.5-vl-72b-instruct` als aktuell konfiguriertes Vision-Modell)
- `app/reference/loader.py` — Laden der Referenzdaten (JSON und YAML)
- `app/db/history_store.py` — SQLite-basierter History-Store für Duplikaterkennung über mehrere Bearbeitungsperioden

### 4.2 Referenzdaten (Ist-Stand)

| Datensatz | Umfang | Quelle | Pflegestand |
|---|---|---|---|
| `data/referenz/goae_ziffern.json` | 2.843 Ziffern | amtliche GOÄ 1996 mit Anpassungen | OL-006 — Referenz GOÄ amtlich |
| `data/referenz/goz_ziffern.json` | 215 Ziffern | amtliche GOZ | aktuell |
| `data/referenz/goae_annotations.json` | Analog-Ziffern, Hinweise | Eigenaufbereitung | gepflegt |
| `app/reference/goae_ausschluesse.yaml` | 13 Paare | Marktstandard; Beleg OL-061 — Ausschlussregeln GOÄ | in Umsetzung |
| `app/reference/haeufigkeitsregeln.yaml` | 27 Regeln | Eigenaufbereitung; OL-069 — Fach-Review Regeln | Review offen |
| `app/reference/grundleistungen.yaml` | 9 Abhängigkeiten | Eigenaufbereitung; OL-069 — Fach-Review Regeln | in Umsetzung |
| `app/reference/goaeneu_parallel_schema.yaml` | Schema-Stufe 0 | Vorbereitungs-Stub für 2027 | OL-068 — GOÄneu Schema |
| `data/referenz/bema_z_ziffern.json` | 34 Ziffern | BEMA-Z | **nicht im Checker** |
| `data/referenz/ego_ziffern.json` | 40 Ziffern | E-GO | **nicht im Checker** |

### 4.3 Abdeckung nach Prüfart

| Prüfart | Status | Referenz |
|---|---|---|
| Unbekannte GOÄ/GOZ-Ziffern | produktiv | `checker.py` |
| Steigerungsfaktor > 2,3 ohne Begründung | produktiv | Konstante `FAKTOR_SCHWELLE = 2.3` |
| Steigerungsfaktor > 3,5 (formeller Verstoß) | produktiv | Konstante `FAKTOR_MAX = 3.5` |
| Begründungsqualität §5 Abs. 2 (LLM) | produktiv | `analyzer.py` |
| Analog-Ziffer korrekt gekennzeichnet | produktiv | `checker.py`, Annotations-JSON |
| GOZ/GOÄ-Kombinationsverbote | produktiv (13 Paare) | OL-061 |
| Häufigkeitsregeln | produktiv (27 Regeln) | OL-069 |
| Orphan-Addons (Zuschläge ohne Grundleistung) | produktiv (9 Abhängigkeiten) | OL-069 |
| Betragsplausibilität (Punktwert × Faktor) | produktiv | `checker.py` |
| Mehrfacheinreichung innerhalb eines Antrags | produktiv | `checker.py` |
| Mehrfacheinreichung periodenübergreifend | produktiv (SQLite) | OL-074 |
| BEMA-Z-Ziffern | **nicht integriert** | Daten vorhanden |
| E-GO-Ziffern | **nicht integriert** | Daten vorhanden |
| GOÄneu-Stufe (Zuschlagssystem) | **Schema-Stub** | OL-068 |

### 4.4 Integration in die chacha-Architektur

- Die Prüfergebnisse werden über eine Activity in den Temporal-Workflow zurückgeführt und in der DSL-Regelkette weiterverarbeitet (Routing: DV, assistiert, abgelehnt; siehe [`architecture.md`](../architecture.md) — Temporal-Orchestrierung, deterministische Regelkette, LLM-Activities).
- Die LLM-Analyse der §5-Abs.-2-Begründungen hat im Frontend ein eigenes Panel (Sachbearbeiter-HITL); Annahme und Änderung werden als Kontextnotiz (KN) gespeichert und fließen in das Regelwerk-Tuning zurück.
- Die periodenübergreifende Duplikaterkennung ist BFF-seitig implementiert; die samba-Integration (Abgleich mit Bestandsdaten im System of Record) ist **offen** (OL-074).

### 4.5 Dokumentierte Lücken

Aus dem Repository und dem Open-Loops-Tracking:

- **OL-006 — Referenz GOÄ amtlich** — GOÄ-Referenzdaten stammen aus der Fassung 1996 mit Anpassungen; der externe Blocker (amtliche konsolidierte Fassung) ist nicht durch chacha verursacht.
- **OL-068 — GOÄneu Schema** — GOÄneu 2027: Schema-Stufe 0 vorhanden, amtliche Ziffern blockiert durch Veröffentlichungsstand.
- **OL-069 — Fach-Review Regeln** — Review der Orphan-Addons und Häufigkeitsregeln offen; Implementierung basiert auf Marktstandard-Recherche, nicht auf amtlicher Normalisierung.
- **OL-074 — samba Duplikate** — samba-Integration der Duplikaterkennung offen.
- **Unit-Tests im `goaegoz-tool`-Paket**: keine dedizierten Unit-Tests dokumentiert (OL-Kandidat); Regressionen laufen aktuell über Integrationstests der DSL-Szenarienkette.
- **BEMA-Z / E-GO**: Daten vorhanden, Integration offen (Kandidat OL).

### 4.6 Reifegradklasse

Die Reifegradklasse nach dem chacha-Modell lautet für die vier Hauptpfade: **assistiert**. Für Routinerechnungen mit einstelliger Ziffernanzahl und unstrittigem Faktor ≤ 2,3 ist die technische Voraussetzung für Dunkelverarbeitung noch nicht erfüllt; sie hängt von den offenen Baustellen in Abschnitt 4.5 sowie von einem dokumentierten Qualitätsnachweis für die Regelkette ab. Das politisch-organisatorische GoLive-Datum ist Ende 2026 vorgesehen (DSFA-Formalisierung und AVV-Abschluss in der letzten Epoche).

---

## 5. Marktübersicht (Buy-Seite)

### 5.1 Methodik der Marktrecherche

Die Recherche erfolgte am 20. April 2026 über die Hersteller-Websites, deutsche Vergabeportale (vergabe24.de, evergabe.com) und Fachpresse. Jede Kernaussage ist in `docs/assessments/sources/sources.jsonl` mit Abruf-URL und Datum belegt. Nicht öffentlich belegbare Werte (Lizenzbereiche im Einzelfall, interne FTE-Zuordnungen der Landesämter) sind entsprechend gekennzeichnet (Hinweis „nicht öffentlich belegbar") und in **OL-085** für nachgelagerte Einzelanfragen vermerkt.

### 5.2 Segmente und Anbieter

**Segment A — Regelbasierte Prüfung für Beihilfestellen (zentrale Buy-Option):**

- **ZABAS® (Hersteller Global Side, msg insurance suite) und ZABAS BeiPro (AKDB-Tochter Beihilfe-Service GmbH)** — der einzige am deutschen Markt etablierte Anbieter für das Beihilfe-Prüfsegment mit belegtem öffentlichen Auftragsvolumen. Modular aufgebaut (GOÄ, GOZ, PZN, Heilmittel, Pflege, Unfall), regelbasiert, „Mediziner-geprüftes" Standardregelwerk, Anpassung der Regeln ohne Programmierung laut Herstellerangabe (src-001, src-004, src-006). Einsatz: Bayern, Sachsen, Thüringen (Kooperation LfF Regensburg).

**Segment B — Regelbasierte Prüfung für PKV und Verrechnungsstellen (kein direktes Beihilfe-Gegenstück, aber Funktionsverwandtschaft):**

- **MediClaim / MediCheck** — KI-basierte Prüfsoftware mit 12 automatisierten Prüfschritten, Begründungsvorlagen, Branchenbenchmark über 300.000 Abrechnungsdatensätze (src-011). Laut Website: Fokus auf Versicherte und PKV; keine öffentlich dokumentierte Beihilfe-Vertriebsrichtung.
- **EASYGOÄ / DGPAR** — Privatabrechnungssoftware für Arztpraxen mit GOÄ-Regelprüfungen (Regelausschluss, Höchstwerte, Gebührenberechnung). Typische Nutzung: Leistungserbringer statt Kostenträger (src-010, src-021).
- **T2med** — Praxis-Informationssystem mit GOÄ-Regelwerk-Prüfung während der Leistungserfassung; Haftungsausschluss der Datenqualität; keine Prüfung nach Rechnungserstellung (src-009).

**Segment C — Enterprise-PKV-/Healthcare-Plattformen (LLM-native):**

- **Shift Technology — Betrugswächter KV** — KI-Plattform für Krankenversicherer mit Fraud / Waste / Abuse-Detektion, Claims Triage, Case Management; weltweit über 50 Mio Versicherte, über 100 Mrd EUR analysierte Schadenkosten (src-007, src-008). Marktadressierung: PKV-Unternehmen; keine öffentlich dokumentierte Beihilfe-Implementation.
- **adesso insurance solutions — in|sure Health Claims** — Claims-Management-Plattform für PKV mit automatisierter Leistungsprüfung, Limitkontenverwaltung, gesetzlichen Tarifen (src-012). Kein dokumentiertes Beihilfe-Modul.
- **Bitmarck** — Kern-Software für gesetzliche Krankenversicherer; für Beihilfe oder GOÄ-Prüfung öffentlich nicht belegt (src-021).

**Segment D — Beihilfe-Fachverfahren mit GOÄ-Bezug:**

- **BayBAS** (LfF Bayern, Produkt) — Bayerisches Beihilfeabrechnungssystem, PC-gestützt, Client-Server, setzt ZABAS als Prüfmodul ein (src-005).
- **samba** — Fachverfahren in Niedersachsen, System of Record; kein Drittanbieter-Modul für GOÄ-Prüfung, sondern eigener Workflow.
- MB Fidus, Ethesia BABS, aneco — am Markt genannt; öffentliche Produktinformationen zu GOÄ-Prüftiefe in diesem Segment sind rar, **nicht öffentlich belastbar belegbar** (OL-085).

**Segment E — LLM-native Newcomer (DACH-Gesundheitsprüfung):**

- In der Recherche 2026-04-20 keine deutschsprachigen Reinblut-LLM-Startups gefunden, die ein belastbares GOÄ-/GOZ-Prüfprodukt für öffentliche Auftraggeber positionieren. Shift Technology ist der internationale Claims-KI-Marktführer, aber ohne spezifisches deutsches GOÄ-/GOZ-Regelwerk als Kernprodukt.

### 5.3 Dokumentierter Leitmarkt-Referenzauftrag

| Kriterium | Wert | Beleg |
|---|---|---|
| Vergabestelle | Landesamt für Finanzen Bayern (Kooperation Bayern / Sachsen / Thüringen) | src-003, src-005 |
| Gegenstand | Verlängerung Lizenzen und Beschaffung weiterer Lizenzen ZABAS GOÄ / GOZ / PZN, inkl. Wartung, Pflege, Support | src-003 |
| Geschätzter Auftragswert | 6.149.564,15 EUR netto | src-003 |
| Vertragslaufzeit | 4 Jahre, zweimalige Verlängerungsoption um je 1 Jahr (max. 6 Jahre) | src-003 |
| Verfahrensart | Verhandlungsverfahren ohne Aufruf zum Wettbewerb | src-003 |
| Rechtsgrundlage | Richtlinie 2014/24/EU (Dienstleistungen) | src-003 |

Die Vergabeart **Verhandlungsverfahren ohne Aufruf zum Wettbewerb** ist als Ausnahme zulässig, wenn technische Gründe die Beauftragung eines bestimmten Unternehmens rechtfertigen (§14 Abs. 4 Nr. 2 VgV). Das ist ein starkes Signal, dass der deutsche Markt faktisch als Quasi-Monopol strukturiert ist — mit allen Folgen für Preis und Exit-Kosten.

### 5.4 Reichweite und Lücken der Buy-Option

Keiner der identifizierten Anbieter deckt die **Heilfürsorge nach NBG §§224/224a** öffentlich dokumentiert ab. Die Heilfürsorge ist ein niedersachsenspezifischer Leistungsbereich mit eigenem Runderlass; ein Drittanbieter müsste den Regelstand in einem Einzelvertrag parametriesieren. ZABAS BeiPro ist auf Beihilfe ausgerichtet; eine Heilfürsorge-Parametrisierung ist **nicht öffentlich belegbar** (OL-085).

Keiner der Anbieter bewirbt öffentlich eine **GOÄneu-Readiness 2027** mit konkretem Umschaltungs-Zeitplan (Stand 2026-04-20; Quellen src-017, src-018). Die Ausschreibung in Bayern 2024 umfasst Wartung und Pflege — ob die GOÄneu-Umschaltung darin enthalten ist oder als separate Beauftragung kommt, ist aus der öffentlichen Bekanntmachung nicht erkennbar.

---

## 6. Feature-Vergleichsmatrix (45 Kriterien)

Die Matrix vergleicht das chacha-`goaegoz-tool` (Make) mit dem Marktführer-Paket **ZABAS BeiPro** (Buy-Kern) sowie, wo informativ, mit **MediCheck** (alternatives regelbasiertes Produkt) und **Shift Technology** (Enterprise-Claims-KI).

Legende: **V** = voll abgedeckt; **T** = teilweise / Einschränkungen; **O** = offen / nicht im Produkt; **?** = nicht öffentlich belegbar.

| # | Kriterium | chacha (Make) | ZABAS BeiPro (Buy) | MediCheck | Shift |
|---|---|---|---|---|---|
| A — Fachliche Abdeckung GOÄ/GOZ |
| 1 | GOÄ-Ziffern Gesamtabdeckung | V (2.843) | V (vollständig laut Anbieter) | V | ? |
| 2 | GOZ-Ziffern Gesamtabdeckung | V (215) | V | V | ? |
| 3 | Analog-Ziffern korrekt gekennzeichnet | V | V | V | ? |
| 4 | Steigerungsfaktor-Schwellen (2,3 / 3,5) | V | V | V | ? |
| 5 | §5-Abs.-2-Begründung inhaltlich bewertet | V (LLM) | T (Regelwerk, keine Inhaltsanalyse) | V (KI-basiert laut Anbieter) | T |
| 6 | Kombinationsverbote (GOZ/GOÄ) | V (13 Paare) | V (umfassend laut Anbieter) | V | ? |
| 7 | Häufigkeitsregeln | V (27) | V | V | ? |
| 8 | Orphan-Addons / Zuschlagsabhängigkeiten | V (9) | V | T | ? |
| 9 | Betragsplausibilität (Punktwert × Faktor) | V | V | V | V |
| 10 | Mehrfacheinreichung im Antrag | V | V | V | V |
| 11 | Mehrfacheinreichung periodenübergreifend | V (SQLite) | V | ? | V |
| 12 | BEMA-Z (Zahnmedizin GKV) | O (Daten vorhanden) | V (Modul) | O | O |
| 13 | E-GO (Gebührenordnung für Heilpraktiker) | O (Daten vorhanden) | T | O | O |
| 14 | Heilmittel-Verordnungsprüfung | O | V (Modul) | O | O |
| 15 | Arzneimittelprüfung (PZN) | O (in chacha separat) | V (Modul ZABAS PZN) | O | O |
| B — Verfahrensrechtlicher Rahmen |
| 16 | Beihilfe (NBhVO) abgebildet | V | V | T | O |
| 17 | Heilfürsorge (NBG §§224/224a) abgebildet | V (im Routing; Regelstand Baustein) | ? (nicht öffentlich belegbar) | O | O |
| 18 | Bescheid-fertiger Befund | V (Integration mit chacha-Kette) | V (Schnittstelle zu BayBAS) | T (Export) | O |
| 19 | Menschliche Letztentscheidung / HITL integriert | V (BFF) | V (über Fachverfahren) | T | T |
| 20 | Nachvollziehbare Begründungstexte für Bescheid | V | V (Standardtexte) | V | T |
| C — Rechts- und Governance-Dimension |
| 21 | EU-AI-Act-konforme menschliche Aufsicht dokumentiert | V (Drei-Schichten-Architektur und Aufsichtsmaßnahmen im Repository dokumentiert) | ? (Herstellerangabe, nicht öffentlich dokumentiert) | ? | ? |
| 22 | Erklärbarkeit der Regeln offen einsehbar | V (Repository, DSL-Regeln in YAML/JSON) | T (Regel-Editor laut Anbieter, aber proprietär) | T | O (ML-basiert) |
| 23 | Audit-Trail (SHA-Kette) | V (chacha-Ledger) | T (herstellerspezifisch) | ? | T |
| 24 | DSGVO Art. 9 lit. b-Rechtsgrundlage berücksichtigt | V | V | V | V |
| 25 | Drittlandsübermittlung vermeidbar | V (On-premises / DE-Cloud) | V (DE) | ? | T (Konzernstruktur FR/US) |
| 26 | AVV / TOM-Dokumentation erforderlich | n. a. (Eigenbetrieb) | Pflicht | Pflicht | Pflicht |
| 27 | §203 StGB: Drittanbieter als mitwirkende Person | n. a. | einschlägig | einschlägig | einschlägig |
| D — Technische Dimension |
| 28 | On-Premises / Souveräne Cloud möglich | V | V | ? | ? |
| 29 | Modulare API (REST, OpenAPI) | V (FastAPI) | T (Integration über Fachverfahren) | T | V |
| 30 | Eigenes Regelwerk ohne Hersteller-Abhängigkeit | V | O | O | O |
| 31 | LLM-Vision-OCR integriert | V | ? | V (laut Anbieter) | V |
| 32 | Integration mit samba (niedersachsenspezifisch) | realisierbar (BFF) | Einzelprojekt nötig | O | O |
| 33 | Integration mit BayBAS (bayernspezifisch) | nicht relevant | V | O | O |
| 34 | Offene Datenformate (JSON/YAML) | V | T (Produktformat) | T | V |
| 35 | Open-Source-Komponenten / Lizenz-Transparenz | V | O (proprietär) | O | O |
| E — Pflege- und Lebenszyklus |
| 36 | GOÄneu 2027-Readiness dokumentiert | T (Schema-Stufe 0, OL-068) | ? (nicht öffentlich belegbar) | ? | ? |
| 37 | Aktualisierung bei normativen Änderungen | durch Landespersonal | durch Hersteller | durch Hersteller | durch Hersteller |
| 38 | Versionierung und Regel-Deployment | V (Git, versionierte Architekturentscheidungen im Repository) | T (herstellergeführt) | T | T |
| 39 | Exit-Option (Wechsel zu anderem Produkt) | hoch (Eigentum am Code) | niedrig (Vendor-Lock) | mittel | niedrig |
| 40 | Abhängigkeit von Hersteller-Lebensdauer | keine | hoch | hoch | hoch |
| F — Wirtschaftliche Dimension |
| 41 | Lizenzkosten pro Jahr | entfällt | ca. 1 Mio EUR / Jahr (Hochrechnung aus src-003) | nicht öffentlich | Enterprise-Tarif |
| 42 | Pflege- und Wartungskosten | Eigenaufwand | enthalten | separat | separat |
| 43 | Interne Entwicklungsaufwendungen | signifikant (aber aktivierbar) | gering | gering | gering |
| 44 | Exit-Kosten | gering | hoch (Datenmigration, Parallelbetrieb) | mittel | hoch |
| 45 | Mengenflexibilität (neue Mandanten) | hoch | vertragsabhängig | vertragsabhängig | vertragsabhängig |

**Befund der Matrix**: Die Eigenentwicklung erreicht 41 von 45 Kriterien auf **V** oder **T**. Die verbleibenden **O**-Positionen betreffen das Modul-Segment außerhalb des GOÄ-/GOZ-Kerns (BEMA-Z, E-GO, Heilmittel, Arzneimittel) und sind planbare Erweiterungen, keine Architekturlücken. ZABAS BeiPro erreicht vergleichbare Abdeckung im Modul-Segment, lässt aber die Heilfürsorge, die Erklärbarkeit-Transparenz und die Exit-Option offen.

---

## 7. Juristische Dimension

### 7.1 Vergaberecht (§§ 103 ff. GWB, VgV, UVgO)

Eine Drittanbieter-Beschaffung für das GOÄ-/GOZ-Modul überschreitet die EU-Schwellenwerte für Dienstleistungen oberhalb der Lieferschwelle (221.000 EUR netto für Liefer- und Dienstleistungen auf Länder- und Kommunalebene, Stand 2026) deutlich. Die Hochrechnung auf Niedersachsen (grob proportional zum bayerischen Volumen von 6,15 Mio EUR über 4 Jahre) liegt im klar EU-pflichtigen Bereich.

Die bayerische Vergabe 2024 wurde im **Verhandlungsverfahren ohne Aufruf zum Wettbewerb** geführt — zulässig nach §14 Abs. 4 Nr. 2 lit. b VgV, wenn aus technischen Gründen kein anderer Anbieter den Auftrag erfüllen kann. Das ist eine starke Indikation, dass ZABAS BeiPro / ZABAS als Monopolprodukt gilt. Für Niedersachsen bedeutet das:

- Ein vollständiges offenes Vergabeverfahren hätte mangels Wettbewerbsteilnehmer im Beihilfe-spezifischen Segment einen hohen Aufwand ohne erwartbare Bieter-Alternative.
- Ein **In-house-Vergabe-Modell** nach §108 GWB (vergaberechtsfrei) wäre **nicht** möglich mit ZABAS BeiPro als externem Anbieter, da Beihilfe-Service GmbH nicht durch Niedersachsen kontrolliert wird.
- Die Eigenentwicklung des Landes Niedersachsen selbst erfüllt die drei In-house-Kriterien des §108 GWB naturgemäß (Kontrolle durch das Land; Wesentlichkeitskriterium durch ausschließlichen Einsatz für Landesaufgaben; keine private Kapitalbeteiligung) und ist vergaberechtsfrei.

**Folge**: Vergaberecht begünstigt die Make-Option. Der Buy-Pfad ist formal zulässig, aber mit hohem Monopolpreis-Risiko verbunden.

### 7.2 DSGVO — Auftragsverarbeitung und technische Schutzmaßnahmen

Der Buy-Pfad erfordert:

- **AVV nach Art. 28 DSGVO** mit ZABAS-Anbieter (Beihilfe-Service GmbH und/oder msg insurance suite); Standardklauseln bei Konzernstrukturen.
- **TOM nach Art. 32 DSGVO** — der Anbieter muss technische und organisatorische Maßnahmen nachweisen, die den Sensibilitätsgrad von Gesundheitsdaten (Art. 9 DSGVO) abbilden. Zertifizierungen (ISO 27001, BSI C5) sind indikativ, nicht hinreichend; die AVV muss die Maßnahmen benennen und kontrollierbar machen.
- **Drittlandsübermittlung** — bei den vier Hauptkandidaten (ZABAS, MediCheck, Shift, adesso) ist für ZABAS (DE-Sitz) und MediCheck (DE-Sitz) das Drittlandsthema entschärft; für Shift (FR mit US-Konzernbezug) ist eine TIA (Transfer Impact Assessment) erforderlich.
- **Verarbeitungsverzeichnis** nach Art. 30 DSGVO muss den Drittanbieter und den Verarbeitungszweck ergänzen.
- **DSFA nach Art. 35 DSGVO** ist für den Einsatz eines KI-basierten Prüfsystems ohnehin Pflicht — für beide Pfade, aber mit unterschiedlichen Betrachtungsschwerpunkten (Make: interne Prozesskontrolle; Buy: Lieferkette, Subdienstleister).

Der Make-Pfad spart die AVV- und TIA-Debatte weitgehend; die Verarbeitung bleibt im Land. Das reduziert das Dokumentationsrisiko, nicht das inhaltliche Datenschutzrisiko — dieses ist in beiden Pfaden gleich hoch.

### 7.3 §203 StGB — Berufsgeheimnis

Beihilfe-Bearbeitung berührt das ärztliche Berufsgeheimnis aus §203 StGB (Absatz 1 Nr. 1) über den vertraulichen Inhalt der ärztlichen Rechnung (Diagnose, Verordnung). Der Tatbestand des §203 StGB unterscheidet zwei Ebenen: **Abs. 2** (Offenbarung durch Amtsträgerinnen und Amtsträger) erfasst die Beschäftigten der Beihilfestelle selbst und gilt in Make und Buy unverändert. **Abs. 3 und 4** ermöglichen die Einbeziehung sonstiger mitwirkender Personen (insbesondere externer Dienstleister im Buy-Pfad) seit der Reform 2017, wenn Auswahl, schriftliche Geheimhaltungsverpflichtung und Überwachung nachweisbar sind (src-020). Die Weitergabe von geschützten Daten an Drittanbieter ist deshalb vor allem im Buy-Pfad einschlägig; dort verlagert sie zusätzliche Kontrollpflichten auf das Land, während die strafrechtliche Verantwortung der Amtsträgerinnen und Amtsträger nach Abs. 2 erhalten bleibt.

Für den Buy-Pfad heißt das: Der Drittanbieter wird in die Kette der Mitwirkenden aufgenommen; Subunternehmer (Rechenzentren, Support, Entwicklungs-Outsourcing nach außerhalb DE) erfordern Kaskaden-Bindung. Der Auftraggeber (Land Niedersachsen) trägt weiterhin die Verantwortung, verliert aber die direkte Kontrolle über Systemkomponenten.

Für den Make-Pfad entfällt diese Kaskade im Kern des Prüfmoduls; für die LLM-Komponente (OpenRouter / Anthropic) besteht sie weiterhin und wird in der DSFA und dem AVV-Prozess behandelt (OL-060).

### 7.4 EU AI Act — Anhang III Nummer 5 Buchstabe a und Art. 14

Die KI-Verordnung stuft in **Anhang III Nummer 5 Buchstabe a** KI-Systeme als Hochrisiko-Systeme ein, die „von Behörden oder im Namen von Behörden" verwendet werden, „um zu beurteilen, ob natürliche Personen Anspruch auf grundlegende öffentliche Unterstützungsleistungen und -dienste haben" (Quelle src-013, src-014). Das trifft auf das Beihilfe- und Heilfürsorge-Prüfmodul — Make _oder_ Buy — vollumfänglich zu.

Daraus folgen für beide Pfade identische Pflichten:

- **Art. 14 — menschliche Aufsicht**: wirksam, nicht bloß formal; EuGH-Rechtsprechung C-634/21 (SCHUFA, 7. Dezember 2023) verhindert Rubber-Stamping (src-015).
- **Art. 10 — Daten-Governance**: Trainingsdaten, Validierungsdaten, Testdaten dokumentiert.
- **Art. 12 — Protokollierung** über den Lebenszyklus.
- **Art. 13 — Transparenz und Information** für betroffene Personen.

Der Make-Pfad kann **nachweisen**, dass die Regeln offen in YAML/JSON im Repository versioniert sind, dass das LLM ein ergänzendes Assistenzmittel zur Begründungsbewertung ist und dass die Entscheidungsfindung auf deterministischer Regelbasis fußt. Der Buy-Pfad erfordert **vertragliche** Zusicherungen zum Vorhalten einer solchen Dokumentation durch den Anbieter; die Nachweisführung verlagert sich aus der Kontrolle des Landes in die Lieferkette.

Die Hochrisiko-Einordnung greift unabhängig davon, ob Eigenbau oder Fremdprodukt eingesetzt wird. Der Unterschied liegt in der Nachweis-Eigentümerschaft.

### 7.5 NBG §95 Abs. 4 und VwVfG §35a

NBG §95 Abs. 4 ist die bereichsspezifische Rechtsvorschrift i. S. v. §35a VwVfG, die ausschließlich automatisierte Entscheidungen für Beihilfe, Heilfürsorge, Heilverfahren, Reise-/Umzugskostenvergütung und Trennungsgeld zulässt, sofern dem Antrag **vollständig entsprochen** wird (src-019). Die Rechtsvorschrift selbst ist vom gewählten Anbieter unabhängig. Die technische Umsetzung der vollständigen Antragsentsprechung (keine Teilabweisung im Dunkelbetrieb) ist hingegen Anbieter-abhängig:

- Make-Pfad: Die Routing-Logik ist in der DSL-Regelkette explizit abgebildet und kann im Audit jederzeit nachgeprüft werden.
- Buy-Pfad: Die Routing-Logik liegt im Produkt; Anbieter-Konfiguration und Abweichungsprotokoll sind erforderlich.

### 7.6 Amtshaftung — Art. 34 GG, §839 BGB

Die Amtshaftung greift gegenüber Beihilfeberechtigten unabhängig davon, ob ein Drittanbieter beteiligt war. Rückgriff des Landes auf den Anbieter bei Pflichtverletzung setzt vertragliche Haftungsregelungen voraus, die in Standard-AVVs häufig limitiert sind (z. B. auf die Jahreslizenz). Für die Make-Option entfällt diese Rückgriffs-Unsicherheit; die fachliche Verantwortung bleibt einheitlich beim Land.

---

## 8. Wirtschaftliche Dimension — TCO-Szenarien

### 8.1 Methodik

Die TCO-Schätzung erfolgt über einen 5-Jahres-Horizont in drei Szenarien. Datenbasis:

- **Marktpreis-Referenz**: bayerische Vergabe 6,149 Mio EUR / 4 Jahre für Module GOÄ, GOZ und PZN = ca. 1,54 Mio EUR / Jahr (src-003). Auf Module GOÄ+GOZ (ohne PZN) geschätzt ca. 1,0–1,2 Mio EUR / Jahr.
- **Eigenentwicklungskosten chacha**: aktiviert in der mToken-Bilanz des Projekts, nicht in EUR-Sätzen; für die externe Vorlage wird die mToken-Metrik nicht verwendet. Die Eigenentwicklungslinie wird über interne Personenmonate approximiert (OL-085 präzisiert den Benchmark bei Bedarf).

Sämtliche Werte sind Orientierungsgrößen. Verbindliche Angebote sind im Vergabe- oder Beratungsverfahren einzuholen.

### 8.2 Szenario A — Buy-pur (Drittanbieter-SaaS ersetzt `goaegoz-tool` vollständig)

| Position | Jahr 1 | Jahr 2 | Jahr 3 | Jahr 4 | Jahr 5 | Summe |
|---|---|---|---|---|---|---|
| Lizenz GOÄ/GOZ (geschätzt) | 1,2 Mio | 1,2 Mio | 1,2 Mio | 1,2 Mio | 1,2 Mio | 6,0 Mio |
| Erstparametriesierung / Onboarding | 0,3 Mio | — | — | — | — | 0,3 Mio |
| Integrationsaufwand samba / chacha-Workflow (interne PM) | 0,4 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,8 Mio |
| Heilfürsorge-Parametrisierung (Einzelauftrag) | 0,2 Mio | 0,1 Mio | — | — | — | 0,3 Mio |
| GOÄneu-Umschaltung (2027, indiziert Jahr 2 oder 3) | — | 0,4 Mio | 0,1 Mio | — | — | 0,5 Mio |
| Ablösung `goaegoz-tool` (Wissensverlust, Umzug) | 0,2 Mio | — | — | — | — | 0,2 Mio |
| **Summe (orientierungsweise)** | **2,3** | **1,8** | **1,4** | **1,3** | **1,3** | **8,1 Mio** |

**Bewertung Szenario A**: Die Kostenposition ist planbar, aber in voller Höhe extern gebunden. Das Eigentum an Regelstand und Daten wandert zum Anbieter; der Wissensaufbau in der Landesverwaltung bleibt marginal. Die GOÄneu-Umschaltung ist als separate Beauftragung zu erwarten — in der Bayerischen Vergabe 2024 ist die Umschaltung nicht gesondert ausgewiesen (src-003).

### 8.3 Szenario B — Buy-hybrid (Drittanbieter-Modul hinter samba-/chacha-Workflow)

Modul-kauf: nur der GOÄ-/GOZ-Prüfkern als Black-Box-API, hinter der bestehenden DSL-Regelkette weiter. Eigenentwicklung trägt Routing, LLM-Begründungsanalyse und Heilfürsorge.

| Position | Jahr 1 | Jahr 2 | Jahr 3 | Jahr 4 | Jahr 5 | Summe |
|---|---|---|---|---|---|---|
| Modullizenz GOÄ/GOZ (50–70 % des Buy-pur-Preises) | 0,8 Mio | 0,8 Mio | 0,8 Mio | 0,8 Mio | 0,8 Mio | 4,0 Mio |
| API-Integration und Parallelbetrieb | 0,3 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,7 Mio |
| Eigenentwicklung Heilfürsorge + DSL-Kette (fortgeführt) | 0,3 Mio | 0,2 Mio | 0,2 Mio | 0,2 Mio | 0,2 Mio | 1,1 Mio |
| GOÄneu-Umschaltung (teils Hersteller, teils eigen) | — | 0,3 Mio | 0,1 Mio | — | — | 0,4 Mio |
| **Summe (orientierungsweise)** | **1,4** | **1,4** | **1,2** | **1,1** | **1,1** | **6,2 Mio** |

**Bewertung Szenario B**: Günstiger als Buy-pur, aber mit Schnittstellen-Haftung und fortbestehender Drittanbieter-Abhängigkeit für den Prüfkern. Bei Hersteller-Insolvenz oder Kündigung verbleibt die schwierigste Komponente ungelöst.

### 8.4 Szenario C — Make-erweitert (Eigenentwicklung fortsetzen, gezielt erweitern)

Eigenentwicklung bleibt Kern; BEMA-Z, E-GO, GOÄneu werden inkrementell erweitert; Vision-OCR bleibt LLM-basiert; Pflegeaufwand durch Landespersonal und Entwicklungspartner.

| Position | Jahr 1 | Jahr 2 | Jahr 3 | Jahr 4 | Jahr 5 | Summe |
|---|---|---|---|---|---|---|
| Fortentwicklung `goaegoz-tool` (interne und externe PM) | 0,6 Mio | 0,5 Mio | 0,4 Mio | 0,3 Mio | 0,3 Mio | 2,1 Mio |
| Erweiterung um BEMA-Z, E-GO, Heilmittel | 0,3 Mio | 0,3 Mio | 0,2 Mio | — | — | 0,8 Mio |
| GOÄneu-Migration 2027 | 0,1 Mio | 0,3 Mio | 0,1 Mio | — | — | 0,5 Mio |
| Regel-Review, Pflegewerkstatt | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,5 Mio |
| LLM-Laufzeit-/OpenRouter-Kosten | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,1 Mio | 0,5 Mio |
| Audits (EU-AI-Act-Konformität, Pentest) | 0,1 Mio | — | 0,1 Mio | — | 0,1 Mio | 0,3 Mio |
| **Summe (orientierungsweise)** | **1,3** | **1,3** | **1,0** | **0,5** | **0,6** | **4,7 Mio** |

**Bewertung Szenario C**: Die Kostenposition fällt niedriger aus als die Buy-Pfade, produziert Eigentum am Regelstand und skaliert über die NLBV-Anforderungen hinaus (HFB, BEMA-Z, GOÄneu). Erhöhtes Ressourcen-Risiko: Personen, die das System kennen, sind kritisch; Risikogegenmaßnahme über Doku-Co-Evolution und breit aufgestelltes Entwicklungs-Ökosystem (siehe chacha-Prinzipien).

### 8.5 Vergleich

| Szenario | 5-Jahres-TCO (Orientierung) | Eigentum an Regelstand | Exit-Kosten | GOÄneu-Readiness | Heilfürsorge-Abdeckung |
|---|---|---|---|---|---|
| A — Buy-pur | 8,1 Mio EUR | Anbieter | hoch | Einzelbeauftragung | Einzelauftrag |
| B — Buy-hybrid | 6,2 Mio EUR | geteilt | mittel | teilweise intern | intern |
| C — Make-erweitert | 4,7 Mio EUR | Land | gering | inkrementell | intern |

Die TCO-Aussage ist keine betriebswirtschaftliche Vollrechnung — Risikoaufschläge, Opportunitätskosten der internen Bindung und Werterhalt durch Eigentum sind qualitativ gewürdigt, nicht monetarisiert. Für die endgültige Entscheidungsvorlage ist eine Vollrechnung nach Landeshaushaltsrecht (LHO) zu führen (OL-085).

---

## 9. Strategische Dimension

### 9.1 GOÄneu 2027 First-Mover

Die GOÄneu-Reform ist ein Einschnitt: rund 5.500 neue Gebührennummern, Wegfall der Steigerungsfaktoren 2,3 / 3,5 zugunsten eines Zuschlagssystems, neue Leistungsbereiche (Telemedizin, digitale Diagnostik, Palliativmedizin). Einigung BÄK/PKV-Verband September 2024; realistischer Zeitrahmen 2027; politisch derzeit auf Eis im BMG (src-017, src-018).

Wer den Umschaltungsmechanismus im eigenen Repository versioniert (Chance C-005 im Register), kann:

- Parallelbetrieb alte GOÄ / GOÄneu abbilden (für Rechnungen mit Leistungsdatum vor / nach der Umschaltung),
- Regelunterschiede in der DSL-Kette transparent machen und dem Sachbearbeiter vor der Bescheidentscheidung anzeigen,
- die Drittanbieter-Neulizenz für die GOÄneu-Umschaltung vermeiden.

### 9.2 Heilfürsorge (HFB) — niedersachsenspezifischer Vorteil der Make-Option

Die Heilfürsorge nach NBG §§224/224a ist ein eigenständiger Leistungsbereich, dessen Regelstand über die Heilfürsorgebestimmungen (Runderlass MI) gepflegt wird. Keines der auf dem Markt sichtbaren Produkte bildet HFB öffentlich dokumentiert ab. Der Make-Pfad hat den HFB-Pfad in der DSL-Regelkette bereits mit gleichwertiger Ausgestaltung zum Beihilfepfad gesichert; der Buy-Pfad würde eine Einzelbeauftragung des Anbieters für die HFB-Parametrisierung erfordern.

### 9.3 Daten-Hoheit und samba-Kopplung

samba ist das niedersächsische System of Record. Die chacha-Architektur koppelt das GOÄ-/GOZ-Prüfmodul über die BFF-Schicht an samba; keine Beleg-Daten verlassen das Landesnetz (abgesehen von der Vision-LLM-Verarbeitung über OpenRouter, siehe DSFA und OL-060). Im Buy-Pfad ist für jede Belegübermittlung an den Anbieter eine vertragliche Datenflussregelung erforderlich — einschließlich der Frage, ob Belege im Klartext oder nur als Token-Hash übermittelt werden (dies schränkt die fachliche Prüftiefe ein).

### 9.4 Skill-Aufbau im öffentlichen Sektor

Der Make-Pfad erzeugt im NLBV und bei den beauftragten Entwicklungspartnern dauerhaftes Know-how über Beihilfe-, Heilfürsorge- und GOÄ-/GOZ-Prüfregeln. Das ist ein Wert, der im Landeshaushalt schwer zu bilanzieren, strategisch aber substantiell ist — insbesondere im Hinblick auf GOÄneu, zukünftige Reformen der NBhVO und die Heilfürsorge-Entwicklung.

---

## 10. Risiken Make vs. Buy

### 10.1 Risiken der Buy-Option (Szenarien A, B)

| Risiko | Wahrscheinlichkeit | Schaden (Wirkung) | Minderungsmaßnahme |
|---|---|---|---|
| Monopolist-Preisspirale (Folgevergabe ohne echten Wettbewerb) | hoch | Budget-Eskalation | mehrjährige Preisgleitklausel im Rahmenvertrag; Exit-Klausel mit Datenübergabe |
| Hersteller-Insolvenz oder Produktabkündigung | mittel | Pflegestau, Mehraufwand bei Wechsel | Source-Code-Escrow; Pflicht zur Dokumentation der Regelbasis |
| GOÄneu-Umschaltung nicht fristgerecht | mittel | Parallelbetrieb, Bescheid-Risiko | vertragliche Meilensteine mit Pönalen |
| Heilfürsorge-Parametrisierung unvollständig | hoch | Fehlbescheide HFB | separate Abnahmephase; Rückfallroute auf Make-Modul |
| AVV-Lücken (Subunternehmer, Drittland) | mittel | Datenschutz-Findings | AVV-Mustertext; Audit-Klausel; TOM-Review |
| Black-Box-LLM im Drittprodukt | mittel | EU-AI-Act Dokumentationslücke | Anbieter-Erklärung zur Hochrisiko-Konformität und Prüfbericht |
| Integrationslast samba (Schnittstellen-Pflege) | mittel | Wartungsaufwand | stabile API, SLA |

### 10.2 Risiken der Make-Option (Szenario C)

| Risiko | Wahrscheinlichkeit | Schaden (Wirkung) | Minderungsmaßnahme |
|---|---|---|---|
| Personen-Einzelabhängigkeit (Know-how-Verlust) | mittel | Stillstand der Pflege | Doku-Co-Evolution; Entwicklungs-Ökosystem mit 2 Partnern; verbindliche Architekturdokumentation im Repository |
| Fach-Review der Orphan-Addons und Häufigkeitsregeln offen (OL-069) | mittel | Regel-Lücken | Audit mit Fachärzten; Vergleich mit marktüblichen Regelwerken (src-009, src-010, src-011) |
| GOÄneu-Umschaltung 2027 abhängig von amtlicher Veröffentlichung | hoch | Verzögerung | Parallel-Schema (OL-068) bereits vorhanden; Umsetzung bei Veröffentlichung |
| LLM-Laufzeitkosten (OpenRouter) schwer kalkulierbar | mittel | Betriebsbudget-Risiko | Rate-Limits, günstiges Haiku-Modell für Klassifikation, Sonnet nur für Begründungs-Qualität |
| Drittlandsübermittlung durch OpenRouter / Anthropic | mittel | Datenschutz-Findings | AVV OpenRouter (OL-060); TIA; ggf. Ersatz durch EU-/DE-Hosting |
| Technische Schulden (fehlende Unit-Tests im Tool-Paket) | niedrig | Regressionen | Tests ergänzen; Integration in CI |

Die Make-Risiken sind **aktiv gestaltbar**, die Buy-Risiken sind zu einem wesentlichen Teil **vertraglich zu sichern** und liegen außerhalb der direkten Kontrolle des Landes.

---

## 11. Entscheidungsmatrix und Empfehlung

### 11.1 Gewichtete Matrix

| Dimension | Gewicht | Buy-pur (A) | Buy-hybrid (B) | Make (C) |
|---|---|---|---|---|
| Fachliche Abdeckung (inkl. HFB) | 25 % | 6 | 8 | 9 |
| Rechtskonformität | 25 % | 6 | 7 | 8 |
| Wirtschaftlichkeit (5-J-TCO) | 20 % | 5 | 7 | 9 |
| Strategie & Daten-Hoheit | 20 % | 4 | 6 | 9 |
| Reifegrad & Risiko | 10 % | 8 | 7 | 6 |
| **Gewichteter Score (max. 10)** | **100 %** | **5,6** | **7,0** | **8,5** |

(Skala 1–10; höher ist besser. Die Bewertung wurde im Licht der Abschnitte 4–10 vergeben; die Gewichte sind offen und von der Leitung zu justieren.)

### 11.2 Empfehlung

**Die vorläufige Empfehlung lautet Szenario C — Make-erweitert.** Die Empfehlung ist **nicht** absolut gegen einen Zukauf, sondern für die Fortführung und gezielte Erweiterung des bestehenden `goaegoz-tool` als Kern, gepaart mit einer Modulstrategie, die Teilfunktionen (Vision-OCR, Datenhaltung, Reporting) beim besten Markt-Bausteinlieferanten beschafft, ohne den Prüfkern aus der Landeshand zu geben.

**Ausdrückliche Offenheit für Neuevaluation** besteht, wenn:

- die Bayerische Folgevergabe (nach 2028) signifikante Preissenkung oder Leistungsausweitung zeigt,
- ein belastbares Heilfürsorge-Modul im Markt erscheint,
- die GOÄneu-Umschaltung signifikant schneller durch einen Anbieter erfolgt als im eigenen Repository,
- personelle Kapazität im NLBV und bei Entwicklungspartnern dauerhaft nicht gesichert werden kann.

### 11.3 Nächste Schritte

1. Interne Abstimmung im NLBV-Auftraggeberkontext zur weiteren Verwendung dieser Einschätzung.
2. **OL-085 — Lizenz-Benchmarks** bearbeiten: formale Angebotsanfragen (ZABAS BeiPro / msg insurance suite / MediCheck), um die Schätzbasis der TCO zu härten.
3. Nach Abschluss der Angebotsanfragen Aktualisierung der Matrix mit belastbaren Preisen.
4. Bei Beibehaltung der Make-Empfehlung: **OL-069 — Fach-Review Regeln**, **OL-074 — samba Duplikate**, **OL-068 — GOÄneu Schema** (Stufe 1) priorisieren und in die Quartalsplanung aufnehmen.

---

## 12. Anhänge

### 12.1 Kurz-Datenschutz-Folgenabschätzung (DSFA) für Szenario A — Buy-pur

Diese Kurz-DSFA skizziert nur die zusätzlichen Anforderungen, die durch den Drittanbieter-Einsatz entstehen. Eine vollständige DSFA nach Art. 35 DSGVO ist bei Entscheidung für einen Buy-Pfad zu erstellen.

**Verantwortlich**: Land Niedersachsen (NLBV), Art. 4 Nr. 7 DSGVO.

**Auftragsverarbeiter**: ZABAS-Anbieter (msg insurance suite / Beihilfe-Service GmbH).

**Verarbeitete Daten**:
- Personenstammdaten (Name, Geburtsdatum, Beihilfenummer, Kassenzeichen)
- Rechnungsinhalte mit Gesundheitsdaten (Art. 9 Abs. 1 DSGVO): Diagnose-Hinweise, Leistungsdaten, Verordnungen, Honoraransätze
- Kontaktdaten der Beleg-Ausstellenden (Ärzte, Krankenhäuser)

**Rechtsgrundlagen**:
- Art. 6 Abs. 1 UAbs. 1 lit. e DSGVO (öffentliches Interesse, Aufgabenerfüllung)
- Art. 9 Abs. 2 lit. b DSGVO i. V. m. NBG §95 und NBhVO (Gesundheitsdaten aufgrund Rechtsvorschrift)
- NBG §95 Abs. 4 (automatisierte Entscheidungsfindung im Rahmen vollständiger Antragsentsprechung)

**AVV-Pflichtfelder (Art. 28 Abs. 3 DSGVO)**:
- Gegenstand, Dauer, Art und Zweck der Verarbeitung
- Art personenbezogener Daten, Kategorien betroffener Personen
- Pflichten und Rechte des Verantwortlichen
- Weisungsgebundenheit des Auftragsverarbeiters
- Vertraulichkeitsverpflichtung aller Zugriffsberechtigten
- TOM nach Art. 32 DSGVO (mit Anlage)
- Subunternehmer-Kaskade mit Zustimmungsvorbehalt
- Unterstützung bei DSFA, DSGVO-Anträgen Betroffener
- Lösch- oder Rückgabepflicht nach Vertragsende
- Audit- und Inspektionsrechte des Verantwortlichen

**TOM-Prüfpunkte**:
- Verschlüsselung at rest (AES-256 oder vergleichbar)
- Verschlüsselung in transit (TLS 1.3)
- Zugriffskontrolle (Rollen, Protokollierung, Passwort-Mindestanforderung, 2FA)
- Auftragskontrolle (weisungskonforme Verarbeitung)
- Verfügbarkeitskontrolle (Backups, Wiederanlauf, SLA)
- Trennungsgebot (mandantenfähige Architektur oder dedizierter Mandant)

**TIA (Transfer Impact Assessment)**: erforderlich, falls Subunternehmer außerhalb EWR. Für ZABAS ist der Hersteller (msg insurance suite) in DE ansässig; TIA wahrscheinlich nicht erforderlich — Prüfung bei Angebotsausgestaltung.

**Einsatz von KI-Modellen**: falls der Anbieter LLM-Komponenten einsetzt, gelten zusätzlich die Transparenz-, Logging- und Aufsichts-Pflichten aus Art. 14 EU AI Act; diese sind in den AVV aufzunehmen.

### 12.2 Abkürzungen

| Kürzel | Bedeutung |
|---|---|
| AI Act | Verordnung (EU) 2024/1689 (KI-Verordnung) |
| AKDB | Anstalt für Kommunale Datenverarbeitung in Bayern |
| AMRabG | Arzneimittelrabattgesetz |
| AVV | Auftragsverarbeitungsvertrag nach Art. 28 DSGVO |
| BayBAS | Bayerisches Beihilfeabrechnungssystem (LfF Bayern) |
| BÄK | Bundesärztekammer |
| BEMA-Z | Bewertungsmaßstab für zahnärztliche Leistungen |
| BFF | Backend for Frontend (chacha-Architektur) |
| DSFA | Datenschutz-Folgenabschätzung (Art. 35 DSGVO) |
| DSGVO | Datenschutz-Grundverordnung |
| E-GO | Gebührenordnung für Heilpraktiker |
| FTE | Full Time Equivalent |
| GKV | Gesetzliche Krankenversicherung |
| GOÄ | Gebührenordnung für Ärzte |
| GOÄneu | Reformentwurf GOÄ (Zeitrahmen 2027) |
| GOZ | Gebührenordnung für Zahnärzte |
| GWB | Gesetz gegen Wettbewerbsbeschränkungen |
| HFB | Heilfürsorge (NBG §§224/224a) |
| HITL | Human in the Loop |
| KN | Kontextnotiz |
| LfF | Landesamt für Finanzen (Bayern) |
| LLM | Large Language Model |
| MediPay / ZABAS | Software-Familie Global Side / msg insurance suite |
| mToken | interne Kapazitätsmetrik des chacha-Projekts |
| NBG | Niedersächsisches Beamtengesetz |
| NBhVO | Niedersächsische Beihilfeverordnung |
| NDSG | Niedersächsisches Datenschutzgesetz |
| NLBV | Niedersächsisches Landesamt für Bezüge und Versorgung |
| NVwVfG | Niedersächsisches Verwaltungsverfahrensgesetz |
| OCR | Optical Character Recognition |
| OL | Open Loop (internes Tracking) |
| PKV | Private Krankenversicherung |
| PM | Personenmonat |
| PZN | Pharmazentralnummer |
| SaaS | Software as a Service |
| samba | Fachverfahren Niedersachsen (System of Record) |
| SLA | Service Level Agreement |
| StGB | Strafgesetzbuch |
| TCO | Total Cost of Ownership |
| TIA | Transfer Impact Assessment |
| TOM | Technische und organisatorische Maßnahmen (Art. 32 DSGVO) |
| UVgO | Unterschwellenvergabeordnung |
| VgV | Vergabeverordnung |
| VwVfG | Verwaltungsverfahrensgesetz |
| ZABAS | Prüfsoftware Global Side / msg insurance suite |

### 12.3 Quellenverzeichnis

Vollständige Quellen mit Abrufdatum: [`sources/sources.jsonl`](sources/sources.jsonl).

Die 22 Quellen decken Anbieter-Websites (ZABAS, AKDB, Shift, MediClaim, EASYGOÄ, T2med, adesso, Bitmarck, Beihilfe-Service GmbH), Vergabeportale (evergabe.com), Rechtsquellen (AI Act Anhang III, Erwägungsgrund 58, NBG §95, §108 GWB), Rechtsprechung (EuGH C-634/21 SCHUFA), Fachpresse (GOÄneu-Reform, BÄK-Präsentation) und Fachkommentare (§203 StGB-Reform) ab. Alle Quellen wurden am 20. April 2026 abgerufen.

### 12.4 Verweis auf weitere chacha-Dokumente

- [`architecture.md`](../architecture.md) — Architekturübersicht inkl. Drei-Schichten-Modell (Temporal-Orchestrierung, DSL-Regelkette, LLM-Activities) und gleichwertiger Ausgestaltung von Beihilfe- und Heilfürsorge-Pfad
- [`beihilfe-assistent-rechtskonformitaet-v3.html`](../beihilfe-assistent-rechtskonformitaet-v3.html) — Rechtliche Einschätzung (kompakt)
- [`gesetzeshierarchie-beihilfe-assistent.html`](../gesetzeshierarchie-beihilfe-assistent.html) — Rechtliche Würdigung mit Randziffern
- [`open-loops.md`](../open-loops.md) — OL-006, OL-060, OL-061, OL-068, OL-069, OL-074, OL-085

---

*Versionshinweis: Dieses Dokument trägt Versionsnummer 1.0. Aktualisierungen nach belastbaren Drittanbieter-Angeboten oder nach der GOÄneu-Veröffentlichung sind vorgesehen; der Folgestand wird als Version 2 im selben Verzeichnis abgelegt.*