Brainversum · tuxametrics Graph Admin

konzept vertraulich owner: matus

Fachlicher Backlog v1.3 — Epic-für-Epic-Analyse und Umsetzungsskizzen

Fachlicher Backlog v1.3 — Epic-für-Epic-Analyse und Umsetzungsskizzen

Status: offen · Adressat: Product Owner (Scope-Entscheidungen) + Entwicklung (die als „sofort baubar" markierten Punkte) · Quelle: referenzfaelle/TuxAmetrics_Fachlicher_Backlog_v1.3.md (2413 Zeilen, 13 Epics F0–F12, laut eigenem Änderungsprotokoll „7 neue fachliche Grundmodelle, 28 neue User Stories, 62 fachlich erweiterte Stories, 1 neues Epic F12, 12 neue Dashboard-/Funktionsblöcke" gegenüber v1.0)

Dieses Dokument beantwortet eine einzige Frage je Story aus v1.3: ist sie im aktuellen Gold Path umgesetzt, teilweise, oder gar nicht — und was würde fehlen? Es ist eine Analyse, kein Umsetzungsauftrag. Kein Wert, keine Schwelle und kein Umrechnungsfaktor in diesem Dokument ist erfunden — wo das Material keine Zahl liefert, steht das explizit als offener Punkt (OF-*), nicht als Vorschlag.

Vergleichspunkt ist ../../guidelines/project/gold-path-scope.md (Stand: Backlog v1.2, 34 Stories im Schnitt), gegengeprüft am tatsächlichen Code in tuxametrics-laborauswertung-service/src/main/java/ und tuxametrics-ui/src/domains/.

⚠ Zwei Befunde, die vor jeder einzelnen Story stehen

1. Die Provenienz von referenzfaelle/ ist ungeklärt — das ist die erste Entscheidung, vor der E2-Entscheidung

C:\dev\tuxametrics\referenzfaelle\ ist git-untracked und liegt außerhalb der Materialzone tuxamed/Bearbeitet/, die CLAUDE.md als die eine fachliche Quelle benennt. Die Zeilennummern von TuxAmetrics_Fachlicher_Backlog_v1.3.md (2413 Zeilen) stimmen mit denen von quelle-01-v1.2.md (2345 Zeilen) nicht überein. Solange nicht entschieden ist, ob v1.3 als quelle-01-v1.3.md in die Materialzone wandert (mit Nachzug von 00-bericht.md §9) oder ob tuxametrics eine zweite, gleichrangige Quelle bekommt, darf keine FACH-NNN Z. nnnn-Angabe im Regelkatalog auf referenzfaelle/ zeigen.

Dieselbe Entscheidung deckt eine positive Überraschung ab: referenzfaelle/TuxAmetrics_Referenzfaelle_v1.0.md trägt intern die Überschrift „v1.1" und enthält 14 vollständig ausgearbeitete Referenzfälle mit erwarteten und ausdrücklich nicht erwarteten Ergebnissen — neuer als Backlog v1.3 selbst, der E-18 noch als offen mit „Entwurf, zwölf Fälle" führt. OF-41 ist damit fachlich fast abgeräumt (nur noch die klinische Bestätigung durch Marc — jeder Fall trägt ein 🔍 dafür), technisch ist aber weiterhin nur 1 von 14 Fällen ausführbar (praxis01-referenzfall-02.json = RF-02). Der Dateiname selbst ist irreführend (_v1.0, Inhalt v1.1) — das gehört korrigiert, unabhängig von der Provenienzfrage.

2. Die Begründung für den Ausschluss von Ebene E2 ist durch v1.3 widerlegt — der Ausschluss selbst ist eine offene Scope-Frage

v1.3 entscheidet E-7: FACH-040 trägt seit dem 10.08.2026 bezifferte Orientierungsbereiche (Zn/Cu, Ca/Mg, Ca/P), FACH-050 ist von sieben auf drei Störungsebenen reduziert, vier Verhältnisse sind bewusst auf Interpretationsstufe 0 gesetzt (OF-01 und OF-02 damit beantwortet). Nach der Leitregel dieses Repos („korrigiert wird, was widerlegt wird; nicht gebaut wird, was neu ermöglicht wird") folgt daraus zweierlei, das nicht vermischt werden darf:

Diese beiden Befunde ziehen sich durch fast jedes Epic unten und werden dort nicht wiederholt, nur referenziert.

Teil 1 — Epics F0, F1, F2, F3, F4, F6, F7 (der Kern des aktuellen Gold Path)

Epic F0 — Produktgrenze & fachliche Governance

FACH-001 — Zweck und Rolle des Systems festlegen — ⚠ teilweise Nicht in der „Enthalten"-Tabelle und nicht in der Ausschlusstabelle. Faktisch abgedeckt: RegulatorikGuard, ADR-0002/0003, SystemsteckbriefService mit der wörtlichen §10-Tabelle. Fehlt die Claims-Liste („verbindliche Grundlage für FACH-071 und alle Reporttexte", [NEU] seit v1.1). Achtung Namensfalle: agentic-engineering/CLAIMS.md ist eine Agenten-Koordinationsdatei, kein Claims-Katalog. Skizze: documentation/claims-liste.md mit zulässigen/unzulässigen Formulierungen; im Systemsteckbrief als zwei Listen mitführen. Unverändert blockiert: die regulatorische Einordnung selbst (E-1/E-20, extern vergeben, in v1.3 unverändert).

FACH-002 — Pilot-Laborprofile und Untersuchungsmaterialien — ✅ im reduzierten Schnittumfang Untersuchungsmaterial trägt die sieben belegten Werte, Matrix ist am MesswertEntity nullable=false, der Referenzabgleich läuft über den Referenzbereich des Messwerts und damit implizit matrixgebunden. Kein Laborprofil-Objekt (Schnitt: ein Profil, Serum). v1.3 unverändert; HMA und Hautspektrometrie bleiben P2. Neu wirksam: Die Matrixregel wird durch FACH-040 v1.3 erstmals scharf — Zn/Cu und Ca/Mg tragen für Plasma und Vollblut Bereiche, die sich um Faktor ~3 bzw. ~6 unterscheiden.

FACH-003 — Analyseumfang und Interpretationsstufen — ⚠ teilweise, mit einer strukturellen Lücke Regelkatalog.PFLICHT_KONTEXTPARAMETER bildet 8 der 9 Zeilen ab. Neu in v1.3: Phosphat, anorganisch (Pflicht-Kontextparameter Albumin-korrigiertes Calcium, Kreatinin/eGFR) — fehlt, gehört an die E2-Entscheidung gekoppelt. Größere Lücke: es gibt keine Parametertabelle. Die Interpretationsstufe ist ein int am FindingEntity, kein gepflegter Katalogeintrag je Analyt × Matrix. Damit sind FACH-027, FACH-039 und das Steckbrief-Widget „Parametertabelle" nicht baubar. Skizze: record Parametereintrag(String analyt, Untersuchungsmaterial matrix, int interpretationsstufe, List<String> pflichtKontextparameter, int aktualitaetsgrenzeMonate, KlinischeTragweite tragweite, String fundstelle) im Regelkatalog — die Stelle, an der E-3, E-5 und E-7 zusammenlaufen.

FACH-004 — Freigabepflicht risikoabhängig — ⚠ teilweise Sammelfreigabe-Verbot für R2/R3 ist umgesetzt. Fehlt die abgestufte Prüftiefe: keine Risikoklasse verlangt heute eine Begründung. Skizze: bei Risikoklasse ≥ R2 und Entscheidungsart ANGENOMMEN/GEAENDERT eine nicht-leere Begründung verlangen (GM-7-konform: Dokumentationsanforderung, keine Therapieentscheidung). Hängt an FACH-009, weil die Empfehlung heute die Risikoklasse des Falls erbt statt eine eigene zu tragen.

FACH-005 — Produktsprache — ❌ bewusst (P1, nicht im Schnitt, v1.3 unverändert).

FACH-006 — Out-of-Scope definieren — ⚠ teilweise Systemsteckbrief.bekannteLuecken ist eine List<String> ohne GM-3-Attribut. Skizze: enum Begrenzungsart {DAUERHAFT, TEMPORAER_ROADMAP} + record Einschraenkung(String text, Begrenzungsart art). Billig, keine offene Fachfrage. v1.3 erweitert die Liste: die vier gestrichenen Verhältnisse tragen ausdrücklich „temporär (Roadmap)".

FACH-007 — Zielpopulation und Ausschlusspopulationen — ✅ im Schnittumfang / ❌ eGFR-Modifikator (bewusst) Fünf Ausschlussgründe im Scope-Gate, GM-7.5 korrekt umgesetzt. eGFR-Modifikator bleibt draußen (v12-nachzug Punkt 4); OF-75 in v1.3 unverändert offen.

FACH-008 — Nutzerqualifikation und Eskalationspfad — ⚠ teilweise, drei Lücken (a) Anzeigesteuerung „Risikoklasse × Verfügbarkeitsklasse" fehlt: verfuegbarkeitsklasse wird nie gesetzt. (b) Keine Dringlichkeitsstufe — OF-31 unverändert offen, hier keine Werte erfinden. (c) Qualifikation ist Feld im FreigabeAntrag, kein Nutzerprofil-Attribut.

FACH-009 — Risikoklassifizierung von Interventionen — ❌ nicht umgesetzt (bisher unentdeckte Lücke) P0, im Schnitt, aber kein Interventionskatalog im Repo. baueEmpfehlung setzt e.setRisikoklasse(a.getRisikoklasse()) — die Empfehlung erbt die Risikoklasse des Falls, statt selbst klassifiziert zu werden. Skizze: Regelkatalog.INTERVENTIONSKLASSE: Map<String, record Interventionsklasse(Risikoklasse, Verfuegbarkeitsklasse, String fundstelle)>, befüllt mit den fünf in GM-2 namentlich genannten R2-Stoffen. Offener Punkt (neu): GM-2s Aufzählung ist „u. a." — nicht abschließend —, und die Verfügbarkeitsklasse je Intervention ist im Material nirgends zugeordnet.

Funktion „Scope-Gate" — ⚠ teilweise: von vier Prüfschritten laufen zwei (Zielpopulation, Einwilligung); Nutzerqualifikation und Laborprofil/Material werden nicht geprüft.

Dashboard „Systemsteckbrief" — ⚠ teilweise: Regelwerksversionen, bekannte Lücken, §10-Tabelle, beide externen Fragen vorhanden. Fehlen: Widgets „Parametertabelle"/„Unterstützte Laborprofile". Neu aus v1.3: der ausdrückliche Ausweis, dass Na/K, Fe/Cu, Ca/K, Na/Mg nicht bewertet werden — v1.3 begründet das damit, dass Speziallabore diese mit hausinternen Normen ausdrucken und ihr Fehlen sonst als Extraktionslücke missverstanden würde.

Dashboard „Klinische Governance" — ❌ bewusst (P1, hängt an F9/F12).

Epic F1 — Patienten- und Fallmanagement

FACH-010 — Patientenübersicht — ⚠ teilweise Suche ✅. Fehlen am Patient-Record: „Anzahl/Status vorhandener Auswertungen" und „offener Eskalationshinweis/kritischer Befund auf Patientenebene". Die vorhandene „Sicherheit"-Spalte zeigt dauerhafte Merkmale nach FACH-018, nicht offene Eskalationen — zwei fachlich verschiedene Dinge unter einem Spaltennamen. Skizze: Patient um anzahlAuswertungen, anzahlOffeneAuswertungen, hoechsterOffenerSicherheitsstatus; eine Projection-Query, kein Loop.

FACH-011 — Patient mit klinischem Basisdatensatz — ✅ umgesetzt. referenzGeschlecht bleibt Freitext (OF-16, unverändert).

FACH-012 — Patientenakte öffnen — ✅ umgesetzt.

FACH-013 — Neue Auswertung anlegen — ✅ umgesetzt (Scope-Gate beim Anlegen).

FACH-014 — Auswertungsübersicht mit Filtern — ⚠ teilweise Sortierung korrekt (sicherheitsstatus desc, createdDate desc), Filter fehlt: queryByTenantKey kennt nur bearbeitungsstatus, nicht „kritischer Befund offen"/„Eskalation offen" getrennt von „Prüfung erforderlich". Skizze: Parameter durchreichen, zwei Filter-Chips im UI. Risikohinweis: die Sortierung verlässt sich auf die Ordinalfolge von Sicherheitsstatus — jede Enum-Erweiterung verschiebt sie still.

FACH-015 — Fallnotizen — ❌ bewusst (P1).

FACH-016 — Auswertung archivieren — ✅ umgesetzt, über den dokumentierten Schnitt hinaus (gehört bei Gelegenheit in gold-path-scope.md nachgetragen).

FACH-017 — Aktualität der klinischen Basisdaten — ⚠ teilweise, beste Aufwand-Wirkung in F1 Die Wirkung ist vorbildlich (blockiert Therapieableitung, nicht Interpretation). Die Fristen fehlen vollständig: basisBestaetigt ist Boolean ohne Datumsprüfung. Belegt: 6 Monate für Körpergewicht, jede Auswertung für Schwangerschaft/Stillzeit. Auch fehlend: Erhebungsdatum je Angabe statt eines einzigen Datensatzdatums. Offener Punkt (neu): ob die 6 Monate ab Erhebung oder ab letzter Bestätigung laufen, sagt das Material nicht — strengere Lesart (ab Erhebung) wählen, Wahl dokumentieren.

FACH-018 — Dauerhafte klinische Sicherheitsmerkmale — ✅ umgesetzt, eine Feinheit offen „Kann die Erzeugung verhindern oder die Risikoklasse anheben" — Kontraindikationsart.RELATIV existiert im Modell, wird aber nirgends ausgewertet, jeder Treffer sperrt absolut. Siehe FACH-044. OF-17 unverändert offen.

Widget „Patientenübersicht"/„Arbeitsliste" — ⚠ beide teilweise, siehe FACH-010/FACH-017.

Epic F2 — Intake, Anamnese und Laborbefunde

FACH-020 — Anamnese erfassen — ⚠ teilweise, OF-28 teilweise abbaubar Umgesetzt: 2 von 8 Bereichen (anamneseDialyse, anamneseOnkologischeSystemtherapie). Fehlt u. a. das Beschwerdebild/der Anlass — ohne den ist kein Red-Flag-Abgleich möglich. Die dokumentierte Begründung OF-28 („Werteraum nicht festgelegt") gilt nachgemessen nur noch für einen von acht Bereichen (Alkoholkonsum-Kategorie); GI-Resorptionsstörung, Schilddrüsenerkrankung, Ernährungsform, Rauchstatus sind in v1.3 aufgezählt, Nieren-/Leberfunktion sind Booleans, Allergien sind Freitext. Skizze: vier Enums + zwei Booleans + zwei Freitextfelder; OF-28 auf Alkoholkonsum verengen.

FACH-021 — Medikation auf Wirkstoffebene — ⚠ Erfassung teilweise / ❌ Prüfung bewusst OF-07 (Handelsname → Wirkstoff) durch v1.3 nicht entkräftet. Fehlt an der Erfassung: Einnahmedauer/-beginn bei Dauertherapie (belegt, keine offene Frage) und ein Ausweis, welche Wirkstoffe prüfbar wären.

FACH-022 — Supplementierung mit elementarem Gehalt — ⚠ teilweise Trennung Verbindungsmenge/elementarer Gehalt, OFFEN-Zustand statt Default, Aggregation, Applikationsform — gut. Fehlt die Umrechnungstabelle (13 Zeilen, 9 beziffert, v1.3 unverändert gegenüber v1.2). Skizze: Regelkatalog.ELEMENTARER_ANTEIL mit den neun Werten; die vier „Herstellerangabe maßgeblich" bleiben geführte Einträge ohne Wert (erzwingen OFFEN).

FACH-023 — Einwilligungsstatus — ✅ vollständig.

FACH-024 — Labor-PDF hochladen — ❌ Upload / ❌ Aktualitätsgrenze (v12-Nachzug, unverändert) Kein Dokumenten-Upload (bewusst). Aktualitätsgrenze wird nicht geprüft (3/6/12 Monate je Analytgruppe, seit E-3 entschieden). Wirkung wäre eine Kappung, kein Ausschluss.

FACH-025 — Laborwerte manuell erfassen — ✅ de facto (P1, einziger gebauter Erfassungsweg).

FACH-026 — Strukturierter Import — ❌ bewusst (P1, OF-65 unverändert).

FACH-027 — Intake-Vollständigkeit prüfen — ⚠ teilweise, echte Lücke im Schnitt Keine Vorab-Prüfung — die Information entsteht erst nach dem Auswertungslauf. Skizze: read-only GET .../intake-bereitschaft als Trockenlauf der Kappungsanalyse; dieselbe Logik wie im Auswertungslauf, nicht duplizieren. Vollständig beantwortbar erst mit der Parametertabelle aus FACH-003.

FACH-028 — Präanalytische Bedingungen — ⚠ teilweise Fünf Pflichtangaben erfasst; Hämolyse × Kalium sauber gebaut (Probenprüfhinweis statt Notfallhinweis, ZURUECKGEHALTEN). Fehlt die analytbezogene Zuordnungstabelle (8 Zeilen seit v1.1). Magnesium + Hämolyse ist belegt und nicht verdrahtet. Vorsicht: nur für Kalium ist die Systemreaktion beschrieben; für die übrigen fünf steht nur die Messfehlerrichtung — nicht gleichsetzen.

FACH-029 — Red-Flag-Screening im Intake — ❌ gar nicht umgesetzt — größte Einzellücke in F2 P0, im Schnitt, Katalog seit E-4 freigegeben (8 Einträge), eigener Referenzfall RF-09. FindingTyp.RED_FLAG_TREFFER existiert und wird nie erzeugt. Skizze: enum RedFlag (8 Werte) + Treffererfassung; erzeugeE1Findings erzeugt je Treffer ein unbearbeitetes Finding → R3 → Sperre über den vorhandenen SICHERHEITSEBENE_E1_UNBEARBEITET-Pfad. Der gesamte Wirkpfad existiert bereits — es fehlt nur die Eingangsseite. Strukturelle Änderung nötig: Screening läuft vor und unabhängig von der Laborauswertung.

FACH-052 — Patientenpräferenzen — ❌ bewusst (P1), aber die Begründung fällt mit v1.3: sie hängt an FACH-051, das ohne E2 nicht existiert. Kommt E2, fällt die Begründung — gehört als Folgeabhängigkeit in den E2-Entscheid.

Funktion „Intake-Bereitschaft" — ❌ (s. FACH-027). Widget „Aktuelle Zufuhr je Element" — ⚠: existiert als package-private Methode, nirgends exponiert.

Epic F3 — Extraktion fachlich prüfen

FACH-030 — Extrahierte Laborwerte anzeigen — ✅ weitgehend.

FACH-031 — Prüfbedarf nach Unsicherheit und klinischer Tragweite — ⚠ eine von zwei Dimensionen Erkennungsunsicherheit und Pruefstatus vorhanden; klinische Tragweite fehlt vollständig (E-5, v1.3 unverändert). Ohne sie: Pruefstatus faktisch manuell, das Freigabe-Gateway nicht automatisch entscheidbar, FACH-079s Blockadekategorie „unsichere Extraktion bei hoher Tragweite" nicht baubar. Skizze: enum KlinischeTragweite {NIEDRIG, MITTEL, HOCH, HOCH_WEGEN_HEBELWIRKUNG} — vier Stufen (OF-76: das Widget in v1.3 nennt weiterhin drei und verliert dabei genau die Stufe, die die CRP/Albumin-Blockade trägt).

FACH-032 — Extrahierten Wert korrigieren — ✅ weitgehend Lücke: MesswertKorrektur erlaubt nicht die Korrektur des Referenzbereichs, obwohl die Story ihn nennt.

FACH-033 — Originalbefund neben Extraktion — ❌ (ohne Dokumenten-Upload gegenstandslos).

FACH-034 — Unbekanntes Laborformat — ❌ bewusst (P1).

FACH-035 — Fehlende oder uneindeutige Werte — ✅ umgesetzt.

FACH-036 — Konflikt zwischen mehreren Befunden — ❌ bewusst (P1, braucht mehrere Dokumente, OF-56 unverändert).

FACH-037 — Einheiten normalisieren und Umrechnung absichern — ⚠ die deutlichste ungebaute Sache in F3 11-Zeilen-Tabelle seit E-6 freigegeben, steht nicht im Regelkatalog. Das System rechnet nicht um und prüft nichts — weder Scope- noch Zahlenfrage, die Story liegt im Schnitt. Skizze: matrixbezogener Schlüssel (analyt|matrix|vonEinheit|nachEinheit); Faktor gefunden → Wert, Einheit, Faktor und beide Referenzgrenzen umrechnen; kein Faktor → Pruefstatus.PFLICHT. Harte Vorbedingung für E2 (v1.3 verlangt Verhältnisse auf Stoffmengenbasis).

FACH-038 — Werte außerhalb des Messbereichs — ✅ umgesetzt. Neu wirksam mit v1.3: ein Verhältnis wird nicht berechnet, wenn ein Eingangswert außerhalb des Messbereichs liegt.

FACH-039 — Analyt- und Matrixzuordnung eindeutig machen — ⚠ teilweise. Kein Fuzzy-Matching ✅, aber „auf genau einen Parameterkatalog-Eintrag abgebildet" fehlt (hängt an FACH-003).

Widget „Prüfliste Extraktion" — ⚠ hängt an FACH-031 (vierstufige Fassung!). „Normalisierungsprotokoll" — ❌, hängt an FACH-037. „Nicht verwertbare Angaben" — ⚠, laut v1.3 deckungsgleich mit FACH-047.

Epic F4 — Fachliche Auswertung

FACH-040 — Mineralstoff-Verhältnisse als Kontextmuster — ❌ bisher ausgeschlossen · Ausschlussgrund mit v1.3 entfallen → Scope-Entscheidung (s. Befund 2 oben) Was v1.3 zusätzlich verlangt und beim Bauen zwingend mitgehen muss: Populationsvorbehalt als Pflichtfeld am Verhältnis (nicht ausblendbar — die Bereiche stammen aus einer chinesischen Kohorte, „nicht ohne Weiteres übertragbar"); X-3b-Darstellbarkeit (fehlt, koppelt an OF-73); Verbot, ein Verhältnis-Referenzintervall durch Division zweier Einzelintervalle zu bilden; Vorbehalt der Ablösung durch künftige Pilotlabordaten. Skizze: neue VerhaeltnisEntity, neuer FindingTyp.KONTEXTMUSTER_AUS_VERHAELTNISSEN (E2) — KONSTELLATIONSMUSTER bewusst nicht, OF-03 unverändert offen.

FACH-041 — Werte relativ zum Laborreferenzbereich bewerten — ⚠ teilweise Laborreferenzbereich als Basis ✅, „kein therapeutischer Zielwert" ✅, keine „suboptimal"-Bewertung ✅. Fehlt: funktioneller Zielbereich, E-9 entschieden für fünf Analyte, aber ohne Zahl — Datenmodell vorbereitbar, Bereiche nicht. Hier keinen Wert vorschlagen.

FACH-042 — Klinische Findings erzeugen — ✅ weitgehend. 7 von 9 Typen; mit E2 kommt der achte, der neunte (Konstellationsmuster) bleibt an OF-03 hängen — v1.3 macht nicht ganz E2 baubar, nur den Verhältniszweig.

FACH-043 — Medikament-Mikronährstoff-Interaktionen — ❌ bewusst, OF-07 von v1.3 nicht berührt. Zur Kenntnis: RF-07 im neuen Referenzfallkatalog prüft genau diese ausgeschlossene Regel — ein Signal über die Kundenerwartung.

FACH-044 — Kontraindikationen berücksichtigen — ⚠ teilweise Fehlt: (a) Auswertung von Kontraindikationsart (relativ hebt nur die Risikoklasse an — nirgends ausgewertet); (b) Kontraindikationen aus Anamnese/Medikation/Laborbefunden derselben Auswertung mit Quellenangabe; (c) Vitamin D bei eGFR < 30. Offener Punkt (neu): für die acht FACH-018-Einträge ist absolut/relativ im Material nicht benannt (nur der v1.2-Zusatz Vitamin D/eGFR ist „relativ" eingestuft) — nicht raten.

FACH-045 — Kritische Werte gesondert behandeln — ⚠ wesentliche Lücke, von v1.3 vergrößert Von zehn freigegebenen Schwellen stehen zwei im Regelkatalog (Kalium, eGFR); acht fehlen trotz Freigabe seit E-8. Neu in v1.3: der Ca/P-Abklärungshinweis nach GM-4.4 — laut Material „der am besten belegte Abklärungshinweis des gesamten Regelwerks" — mit einer Besonderheit: setzt den Fall nicht auf R3, unterdrückt aber selektiv nur Calcium-/Vitamin-D-Empfehlungen. Ein dritter Sperrmechanismus neben globaler E1-Sperre und elementbezogener Kontraindikation. Offener Punkt (neu): die Albuminkorrekturformel für Calcium fehlt im gesamten Material (v1.1–v1.3), obwohl FACH-003, FACH-045 und GM-4.4 sie voraussetzen — keine Formel vorschlagen.

FACH-046 — Plausibilitätsauffälligkeiten — ⚠ teilweise (P1). Zwei von fünf Kombinationsbeispielen umgesetzt.

FACH-047 — Nicht abgedeckte Parameter sichtbar machen — ⚠ keine Ansicht, obwohl Datenmodell vorhanden (gekappt). Skizze: ein Endpunkt mit enum Nichtverwertungsgrund (5 Werte) deckt zugleich das F3-Widget ab.

FACH-048 — Begründung eines Findings anzeigen — ✅ vorbildlich.

FACH-049 — Auswertungsunsicherheit sichtbar machen — ❌ bewusst (P1), überlappt mit FACH-047.

FACH-050 — Störungsebene aus Kontextmustern ableiten — ❌ bisher ausgeschlossen · teilweise entkräftet v1.3 reduziert auf drei belegte Störungsebenen (OF-02 beantwortet). Nicht entkräftet: Werteraum der Ausprägungsstärke (OF-32, unverändert). Baubar ist nur der Verhältniszweig, nicht die ganze Story (Konstellationsmuster bleibt an OF-03 hängen).

FACH-051 — Behandlungspriorität bilden — ❌ bisher ausgeschlossen · mit E2 baubar. Erst mit dieser Story bekäme Empfehlungsstatus.ZURUECKGESTELLT überhaupt einen Erzeuger.

Ansicht „Auswertungsergebnis"/Widget „Verhältnisübersicht" — ❌ beide, hängen vollständig an E2.

Epic F6 — Therapieempfehlung

FACH-065 — Strukturierte Therapieempfehlung erzeugen — ⚠ teilweise Nicht gesetzt: Applikationsform, Einnahmefrequenz, Einnahmehinweis (Felder existieren, werden nicht befüllt), Evidenzsäule (Feld fehlt), adressierte Störungsebene (E2). Spannung: die Story sagt „fehlt eine Pflichtangabe, entsteht keine Empfehlung" — der Prototyp erzeugt trotzdem eine (mit OHNE_KONKRETE_DOSIS, durch FACH-067 gedeckt) — eine Auslegung, die sichtbar gemacht werden sollte, nicht nur implizit gilt.

FACH-066 — Empfehlung fachlich begründen — ✅ weitgehend. Fehlen: Evidenzsäule, Störungsebene.

FACH-067 — Empfehlung bei fehlenden Daten zurückhalten — ✅ vorbildlich, Restlücke: Nierenfunktionsprüfung bei renal relevanten Wirkstoffen (braucht eGFR) und „Fehlen der aktuellen Zufuhr blockiert" nicht geprüft.

FACH-068 — Generischen Wirkstoff vor Produkt — ✅ de facto (P1, kein Produktobjekt vorhanden).

FACH-069 — Präparatezuordnung — ❌ bewusst (P2).

FACH-070 — Kritische Befunde von Supplement-Empfehlungen trennen — ✅ funktional, mit toter Enum-Konstante Sperre greift nur global (SICHERHEITSEBENE_E1_UNBEARBEITET), nicht befundbezogen (Sperrgrund.KRITISCHER_BEFUND nie gesetzt). Mit dem Ca/P-Hinweis aus v1.3 wird das relevant — der verlangt genau eine selektive, befundbezogene Unterdrückung.

FACH-071 — Empfehlungssprache festlegen — ⚠ handwerklich erfüllt, strukturell nicht (keine Claims-Liste, keine Prüfung — s. FACH-001). Skizze: Claims-Liste plus ein Test, der erzeugte Begründungstexte dagegen prüft — sonst nicht testbar.

FACH-072 — Dosisobergrenzen und kumulative Gesamtzufuhr — ✅ gut. Unverändert offen, von v1.3 nicht berührt: nationale Höchstmengen (OF-10), Eisen-Sonderregel (OF-67), eGFR-Absenkung.

FACH-073 — Interaktionen zwischen Supplementen — ⚠ 1 von 10 Katalogeinträgen umgesetzt (nur Zink→Kupfer). Fehlen neun, seit E-13 freigegeben. Skizze: record Interaktion(String a, String b, Konsequenz, String bedingung, String fundstelle) mit enum Konsequenz {DOSISANPASSUNG, ZEITLICH_GETRENNTE_EINNAHME, BEGLEITKONTROLLE, SPERRE, FOERDERND_GEZIELT_NUTZEN}. Drei Einträge tragen unbezifferte Schwellen („hohe Dosis") — als geführte, nicht auswertbare Einträge aufnehmen, nicht weglassen.

FACH-074 — Reevaluation und Therapiedauer — ✅ gut. Offener Punkt (neu): „R2 trägt kürzeres Kontrollintervall als R1" — kein Betrag im Material.

Ansicht „Therapieplan-Entwurf" — ⚠ 4 von 7 Blöcken (Interaktionsmatrix, Einnahmeplan, zusammengeführter Reevaluationsplan, Priorisierungssortierung fehlen).

Epic F7 — Klinischer Review & Freigabe

FACH-075 — Klinische Review-Ansicht — ⚠ teilweise. Bestehende Supplementierung erscheint in keiner der zwei Ansichten, obwohl sie Eingangsgröße der Zufuhrbilanz ist. Skizze: supplemente in die Therapieplan-Response aufnehmen — keine offene Fachfrage.

FACH-076 — Empfehlung annehmen — ✅ vollständig.

FACH-077 — Empfehlung ändern — ⚠ teilweise Fehlt: „nach jeder Änderung laufen die Sicherheitsprüfungen erneut, im Moment der Änderung" — heute passiert das erst beim späteren Gesamtplan-Check. Skizze: pruefeNachAenderung(), Ergebnis als Hinweise im Response, ausdrücklich kein 400 — GM-7.2 wörtlich: Regel benennen, Grund benennen, aktiv bestätigen lassen, durchführen.

FACH-078 — Empfehlung ablehnen — ✅ gut. Offen: fallübergreifende Sichtbarkeit zurückgestellter Themen (OF-36, unverändert).

FACH-079 — Offene Pflichtprüfungen vor Freigabe — ⚠ bestes Aufwand-Wirkungs-Verhältnis in F7, unverändert seit v1.2 Heute blockiert alles. E-14 entschieden (6 blockierend, 4 nur Hinweis), unverändert seit v1.2. Fehlt als Blocker: „unsichere Extraktion bei hoher klinischer Tragweite" — ohne FACH-031/E-5 nicht baubar (harte Reihenfolgeabhängigkeit). Skizze: freigabeblocker() auf List<record Freigabepunkt(Kategorie, String, boolean blockierend)> heben, neuer read-only Endpunkt GET .../freigabe-checkliste, zwei getrennte UI-Blöcke.

FACH-080 — Fall final freigeben — ✅ sehr gut. Lücke: Fehlertext verweist auf POST .../korrekturversion, den es nicht gibt — entweder bauen oder Verweis zurücknehmen.

FACH-081 — Review-Aufgabenliste — ❌ bewusst (P1) — „der wahrscheinlichste stille Schaden dieses Produkts" laut implementation-gaps.md. OF-47 unverändert offen.

FACH-082 — Gesamtplan-Sicherheitscheck — ⚠ 4 von 6 Prüfgegenständen. Fehlt: Interaktionen aller Planpositionen untereinander (hängt an FACH-073); Kontraindikationen gegen den finalen statt nur den erzeugten Plan.

FACH-083 — Informierte Übersteuerung dokumentieren — ✅ vorbildlich, eine Modelllücke Übersteuerung ist heute nur an einer gesperrten Empfehlung möglich. v1.3/RF-13 kennt Übersteuerungen ohne vorherige Sperre (z. B. Dosis über Sicherheitswert). UebersteuerungEntity.beruehrteRegel braucht eine zweite Quelle. E-15 (Sichtbarkeitsrollen) liegt in F9; Zweckbindung im Javadoc, nicht im Datenmodell erzwungen (OF-62, unverändert).

Ansicht „Freigabe-Checkliste" — ❌ (s. FACH-079). Widget „Entscheidungshistorie" — ⚠, Daten vollständig, keine eigene Ansicht.

Teil 2 — Epics F5, F8, F9, F10, F11, F12 (überwiegend außerhalb des Gold Path)

Epic F5 — Evidenz & Research

Vollständig draußen (FACH-055–060, OF-13); FACH-061–063 (R-Praxis) ebenfalls draußen. Vorhanden ist nur die Kennzeichnungshälfte: Evidenzgrad, Quellenklasse, Herkunftsebene existieren als Enums an Empfehlung/Finding. Es fehlt durchgängig die Quelle als Objekt — keine Entität mit Titel, Kernaussage, abrufbarer Referenz.

Story P Status Kern
FACH-055 Research nur bei Lücke P0 ❌ Braucht Rechercheauftrag-Entität + „offener Punkt" als eigenes Objekt (OF-25).
FACH-056 Freigegebene Quellenarten P0 ⚠ Q1–Q7-Klassifikation umgesetzt, Policy (Quellenklasse → max. Aussageebene) fehlt (OF-13, Mapping in v1.3 Z. 1356–1368 tabelliert).
FACH-057 Evidenzgrad definieren P0 ⚠ X-3a/X-3b-Teilung fehlt (OF-73); Evidenzsäule fehlt als Feld; „n Quellen je Aussage" nicht abbildbar (heute ein Enum-Wert); Quellenwiderspruch-Blockade unbeantwortet (OF-34).
FACH-058 Research-Ergebnis anzeigen P0 ❌ OF-13-abhängig; zusätzlich OF-33 (Stabilität externer Ablage vs. FACH-119).
FACH-059 „Keine benennbare Grundlage" P0 ❌ Billigste F5-Story, kein Second Brain nötig — Nachbarn (Sperrgrund, ZURUECKGESTELLT) existieren bereits.
FACH-060 Unvollständige Recherche P1 ❌ Folgt aus FACH-055.
FACH-061 R-Praxis-Regeln P2 ❌ Braucht Regelwerk als Daten (wie FACH-108/FACH-120) + OF-12. Plattform (tuxametrics-platform-service/-virtual-identity-service) ist vorhanden, die fachliche Festlegung fehlt.
FACH-062 Praxiseigene Präparatepräferenzen P2 ❌ Braucht FACH-052 + neue Praeparat-Entität.
FACH-063 Vorrang R-Global/R-Praxis P0 (als Dokument) ⚠ E-11 liefert die Tabelle; zwei von vier Teilfragen offen (OF-77).
Widget „Evidenzherkunft" P0 ⚠ 4 von 5 Spalten im Modell, nur als Textzeile im Bericht ausgegeben statt als Widget.

Plattform: kein Neubau; brainversum ist der Kandidat für die Quellenablage, laut eigenem Backlog-Eintrag aber „noch nicht gebaut, nur konzipiert". Kein @zwirn/bpmn-Bedarf.

Epic F8 — Bericht & Kommunikation

Teilweise drin (FACH-085,087,088,090,091), FACH-086 (Patientenversion) und FACH-089 (P1) draußen. BerichtService.therapeutenversion() erzeugt den Bericht als Projektion mit 16 Pflichtabschnitten, drei davon bewusst leer (E2, Behandlungspriorisierung, Quellenverzeichnis).

Story P Status Kern
FACH-085 Therapeutenversion P0 ⚠ 13/16 Abschnitte befüllt. Korrekturbedarf durch v1.3: der E2-Abschnitt trägt die durch E-7 widerlegte Begründung (s. Befund 2 oben).
FACH-086 Patientenversion P1 ❌ Teuerster Punkt in F8. Der Aussagenabgleich der Vergleichsansicht ist mit Berichtsabschnitt.zeilen: List<String> nicht prüfbar — bräuchte Aussagen als identifizierbare Objekte, ein Refactor der Berichtsdomäne. OF-39 (Zuordnungsfrage) unbeantwortet.
FACH-087 Entwurf vor Freigabe P0 ⚠ Entwurfsstatus ✅, aggregierte Anzeige offener Pflichtprüfungen fehlt.
FACH-088 Druck/PDF P0 ⚠ Kein PDF, kein Print-Stylesheet im ganzen UI. Blockiert für die Patientenversion-Unterscheidung durch FACH-086; OF-64 (kein Layout im Material) für serverseitiges PDF.
FACH-089 Praxis-Briefkopf P1 ❌ Braucht Praxis-Stammdaten mit Branding im tuxametrics-platform-service; blockiert durch OF-64.
FACH-090 Sicherheitshinweise P0 ⚠ Katalog vollständig im Regelkatalog, aber im falschen Abschnitt (Systemgrenzen statt je Position); einnahmehinweis existiert in DB, wird nie befüllt/gedruckt; „Ansprechpartner mit Erreichbarkeit" fehlt (braucht tuxametrics-virtual-identity-service + Kontaktdaten). OF-38 unverändert offen.
FACH-091 Verlaufs-/Kontrollplan P0 ⚠ Flache Liste statt Bündelung; geplanteAnwendungsdauer existiert, wird nie befüllt; fällige Kontrollen fehlen in der Aufgabenliste (OF-47, „wahrscheinlichster stiller Schaden").

Einordnung: bestes Verhältnis Restaufwand/Wirkung — vier von sieben Stories sind 70–90 % da.

Epic F9 — Dashboard, Arbeitssteuerung & Pilot-KPIs

Komplett draußen: „P1, misst Pilotbetrieb — es gibt noch keinen" (unverändert durch v1.3; E-1/RegulatorikGuard bleibt UNGEKLAERT). Tragfähig vorhanden: zwirn-audit-service (3 fachliche Ereignisse angeschlossen), Bearbeitungsstatus/Sicherheitsstatus als zwei orthogonale Dimensionen.

Story P Status Kern
FACH-095 Start-Dashboard P0 ❌ Einzige F9-Story ohne Pilotbetrieb-Argument dagegen — steuert den Arbeitstag. Fast vollständig aus vorhandenen Statusfeldern baubar; fällige Reevaluationen fehlen (OF-47).
FACH-096 KPI Bearbeitungszeit P1 ❌ Aus createdDate/Freigabe.zeitpunkt berechenbar ohne neue Felder — lokal aggregieren, nicht über den Audit-Service (der darf keine Gesundheitsdaten tragen).
FACH-097 Acceptance Rate P1 ❌ Datengrundlage vorhanden (Entscheidungsart, Ablehnungskategorie); Pflichthinweis „keine Erfolgskennzahl" fehlt, Kopplung an FACH-102 fehlt.
FACH-098 Häufig geänderte Empfehlungen P1 ❌ Braucht die Richtung der Änderung — heute nur vomTherapeutenVeraendert: boolean, nicht rekonstruierbar.
FACH-099 Feedback nach Auswertung P1 ⚠/❌ zwirn-feedback-service angeschlossen, aber als Bug-Karte, nicht strukturiertes fachliches Feedback.
FACH-100 Pilotkennzahlen exportieren P1 ❌ Ohne Pilot ohne Gegenstand.
FACH-101 Onboarding Testpraxis P1 ❌ Alle fünf geforderten Inhalte existieren bereits (GM-4, GM-7, FACH-083, FACH-121, Systemsteckbrief) — überwiegend eine geführte Oberfläche über Vorhandenem. Der geforderte Demofall „mit bewusst keiner Empfehlung" ist bereits praxis01-referenzfall-02.json.
FACH-102 Klinische Sicherheitskennzahlen P1 ❌ Fünf von acht Kennzahlen grundsätzlich berechenbar. Drei blockiert: Zeit bis Eskalationsbearbeitung (OF-46, keine Zielzeit im Material), Reevaluationstreue (OF-47), Red-Flag-Trefferquote (keine Ausgangsnachverfolgung).

Harte Grenze für F9 insgesamt: OF-68 (Mindestfallzahl, unterhalb derer eine Übersteuerungs-Auswertungszelle leer bleibt) ist unbeziffert. Ohne diese Zahl ermöglicht jede Kennzahlen-Auswertung den Rückschluss auf eine einzelne Praxis/Person — genau das, was E-15/OF-62 ausschließen will. F9 nicht bauen, bevor OF-68 beziffert ist.

Epic F10 — Verlauf & fachliches Lernen

Komplett draußen: „braucht mindestens zwei Auswertungen desselben Patienten über Zeit." Datenmodellseitig günstiger als die Begründung klingt: Patient → Auswertung ist 1:n, vorgaengerAuswertungKey existiert bereits als Feld.

Story P Status Kern
FACH-105 Verlauf zweier Auswertungen P1 ❌ Fünf von sechs Kriterien aus vorhandenen Feldern bedienbar. Eine echte Lücke: der Therapiebezug braucht geplanteAnwendungsdauer, das nie befüllt wird — ohne ihn wäre die Story nur halb erfüllt.
FACH-106 Frühere Therapieentscheidung einsehen P1 ❌ Am billigsten von allen F10-Stories — TherapeutenentscheidungEntity ist vollständig persistiert, es fehlt nur eine patientenübergreifende Abfrage. Nichts blockiert.
FACH-107 Regelkandidaten aus Overrides P1 ❌ Braucht Änderungsrichtung (FACH-098) + Mindestfallzahl/Praxenschwelle (OF-49, unbeziffert) + OF-12.
FACH-108 Regelkandidaten freigeben/ablehnen P1 ❌ Architektonisch teuerste Story: verwandelt Regelkatalog von Java-Klasse in versioniertes Aggregat. Zwei offene Fragen: OF-43 (Auswertung mit noch nicht aktiver Regelversion?), OF-50 (Vetoregel für Referenzfälle existiert nur für UAT nach FACH-116, nicht für diese Story — echte Prozesslücke).
FACH-109 Fachliche Referenzfälle P0 ⚠ fachlich / ❌ technisch S. Befund 1 oben: 14 Fälle vorhanden (TuxAmetrics_Referenzfaelle_v1.0.md, inhaltlich v1.1), nur 1 ausführbar. Bundle-Format erweiterbar (@JsonIgnoreProperties(ignoreUnknown = true) bereits für Erwartungsfelder vorgesehen). RF-12/RF-14 hängen an der E2-Entscheidung.
FACH-110 Schwellen kalibrieren P1 ❌ Kein Code — ein dokumentierter Produktentscheid; die 10:1-Asymmetrie (E-19) ist „Richtwert, keine Kennzahl".

Plattform: FACH-108 wäre ein Kandidat für tuxametrics-process-hub-cockpit/@zwirn/bpmn (mehrstufiger Prozess Kandidat→Prüfung→Freigabe), aber nicht empfohlen als Einstieg — der Engpass ist, dass das Regelwerk Code ist, nicht die Ablaufsteuerung.

Epic F11 — Fachliche Abnahme des Prototyps

Nur FACH-115 im Schnitt gelistet — unterschätzt, was F11 tatsächlich verlangt: der Bewertungsmaßstab für den ganzen Prototyp, drei von vier Stories P0.

Story P Status Kern
FACH-115 Gold-Path-Demofall P0 ⚠ Kernkriterien gegen praxis01-referenzfall-02.json erfüllt (bewusst keine Empfehlung mit sichtbarem Grund ✅), aber „eine angenommen/eine geändert/eine abgelehnt" ist heute Demoskript, nicht Demodaten — zu verifizieren. Mindestens eine E2-Störungsebene ❌ (nicht baubar im aktuellen Schnitt).
FACH-116 Klinische UAT durch Marc P0 ❌ Beantwortet direkt, wonach der Kunde fragen wird. Läuft gegen den vollständigen Katalog (14 Fälle, heute 1 ausführbar), bewertet ausdrücklich das Unterlassen (trifft exakt ADR-0004), hat Vetowirkung unabhängig vom Gesamteindruck. Skizze: 14 Bundles + Erwartungsblöcke, UAT-Lauf-Ergebnisobjekt (Datum, Person, Regelwerksversion, Prüfumfang, Ergebnis). Realistischster Weg zu einer belastbaren „ist das richtig?"-Antwort, ohne eine Fachzahl zu erfinden — die Zahlen stehen im Referenzfallkatalog, tragen dort bereits 🔍 für Marcs Bestätigung.
FACH-117 Prozess-UAT P0 ⚠ Gold Path im UI durchlaufbar; „nächste Aktion an jeder Stelle verständlich" fehlt als explizite Anzeige.
FACH-118 Bekannte fachliche Einschränkungen P0 ⚠ Billigster P0-Punkt in allen 13 Epics. Systemsteckbrief existiert, trägt bereits die Regelwerksversionen. Vier von fünf zusätzlich geforderten Inhalten aus vorhandenen Daten befüllbar (Untersuchungsmaterialien, Ausschlusspopulationen, Analyt-Matrix-Kombinationen < Stufe 4, PilotBetriebsmodus) — Listenfelder an einem existierenden Record.

Epic F12 — Klinische Governance im Betrieb

Nur FACH-119 als mitgeführtes Feld im Schnitt; FACH-120/121 bewusst draußen (Betriebs-, nicht Demofunktionen; 121 zusätzlich durch OF-B2 blockiert).

Story P Status Kern
FACH-119 Regelwerksversion führen P0 ⚠ 3 von 5 Kriterien erfüllt (Version mitgeführt, im Bericht ausgewiesen, SYNTH-Kennzeichnung). Fehlt: Freigabeakt mit Person/Datum (Version ist heute Konfigurationsstring, kein Objekt) und Diff zwischen Versionen. 🔴 Struktureller Konflikt: die Projektions-Architektur des Berichts liest Systemgrenzen/Sicherheitshinweise/Vollständigkeitsprüfung live — ein Deployment mit geändertem Katalog verändert rückwirkend den Inhalt eines bereits freigegebenen, unveränderten Berichts. Im Prototyp folgenlos, im Pilot nicht.
FACH-120 Korrektur-/Nachinformationsprozess P0 ❌ Vier von fünf Kriterien blockiert durch unbezifferte/unbenannte offene Fragen (OF-42, OF-51, OF-52, OF-54); braucht zudem regelscharfe Identität, die Regelkatalog.java nicht hat.
FACH-121 Zulässigkeitsrahmen des Pilotbetriebs P0 ❌ und korrekt so E-1/OF-B2 extern vergeben. RegulatorikGuard ist die heutige, richtige Umsetzung — verhindert, dass die Frage unbemerkt offen bleibt, nicht dass sie offen ist.
FACH-122 Neue Untersuchungsmatrix validieren P2 ❌ Überwiegend ein Validierungsdossier, kein Code; blockiert durch OF-57 (fehlendes Dokument) und OF-19.

Plattform: tuxametrics-virtual-identity-service ist der vorgesehene Ort für „wer darf eine Regel deaktivieren" — existiert bereits, aber die Rolle ist fachlich nicht benannt (OF-42, OF-59, OF-61).

Gesamt-Priorisierungsempfehlung

Zusammengeführt aus beiden Teilanalysen, unter der Leitregel „korrigiert wird, was widerlegt wird; nicht gebaut wird, was neu ermöglicht wird".

Stufe 0 — vor jeder weiteren Zeile Code: zwei Entscheidungen, keine Implementierung.

  1. Provenienz von referenzfaelle/ klären (Befund 1) — blockiert jede Fundstellenangabe auf v1.3 im Code.
  2. Ebene E2 — eigenes ADR, das ADR-0001 Punkt 4 ablöst, plus CLAUDE.md-Änderung (Befund 2). Unabhängig vom Ausgang: die Begründung an den vier betroffenen Stellen (BerichtService, SystemsteckbriefService, RegelkatalogV12Test, CLAUDE.md) ist so oder so korrekturpflichtig.

Stufe 1 — sofort baubar: im Schnitt, freigegeben, keine offene Fachfrage.

  1. FACH-037 Umrechnungsfaktoren (11 Zeilen) — Vorbedingung für E2, deckt laut Material die gefährlichste Fehlerklasse ab.
  2. FACH-029 Red-Flag-Screening — kompletter Wirkpfad existiert bereits, nur die Eingangsseite fehlt.
  3. FACH-045 die acht fehlenden kritischen Schwellen (ohne Calcium — Formel fehlt).
  4. FACH-073 die neun fehlenden Interaktionseinträge.
  5. FACH-022 elementarer Gehalt (9 bezifferte Verbindungen).
  6. FACH-017 Bestätigungsfrist Körpergewicht (6 Monate).
  7. FACH-118 — fünf Listenfelder an einem existierenden Record, höchster Nutzen je Zeile im ganzen Dokument.
  8. FACH-090/091 fertig durchreichen (einnahmehinweis, geplanteAnwendungsdauer existieren, werden nie befüllt).
  9. FACH-059 „keine benennbare Grundlage" — kein Second Brain nötig.
  10. FACH-106 frühere Therapieentscheidungen einsehen — reine Abfrage über bereits persistierte Daten.
  11. Kleinteilig: FACH-014 Sicherheitsfilter · FACH-047 Gegenprobe-Endpunkt · FACH-032 Referenzbereich korrigierbar · FACH-075 Supplemente in die Review-Ansicht · FACH-006 GM-3-Attribut · FACH-080 toten Verweis auflösen · FACH-095 Start-Dashboard (bis auf OF-47).

Stufe 2 — die Abnahmefähigkeit (das, wonach der Kunde fragen wird).

  1. FACH-116 klinische UAT vorbereiten: 14 Fälle als Bundles + Erwartungsblöcke, UAT-Lauf-Ergebnisobjekt mit E1-Vetoregel. Voraussetzung: Marcs 🔍-Bestätigung je Fall; RF-12/RF-14 hängen an der E2-Entscheidung.
  2. FACH-117 sackgassenfrei belegen + „nächste Aktion" anzeigen.

Stufe 3 — der eine strukturelle Punkt, der drei Epics gleichzeitig entsperrt. FACH-119 zu Ende führen: Regelwerksversion als Objekt statt Konfigurationsstring, mit Freigabeakt. Gemeinsame Voraussetzung von FACH-108 (F10), FACH-120 (F12), FACH-061 (F5) — und löst zugleich den Live-Projektions-Konflikt bei FACH-119 selbst.

Stufe 4 — die v1.2-Nachzüge, unverändert durch v1.3, in zwingender Reihenfolge. E-5 (FACH-031, vier Tragweite-Stufen) → dann erst E-14 (FACH-079, blockierend vs. Hinweis — umgekehrt bleibt eine Kategorie dauerhaft leer) → E-3 (FACH-024, Aktualitätsgrenzen, unabhängig) → zuletzt E-2 (eGFR-Modifikator, teuerster Nachzug, zieht drei weitere Punkte nach).

Bewusst zurückstellen, mit Begründung — nicht aus Aufwand:

Nicht bezifferte Punkte, die quer über mehrere Epics im Weg stehen (keine davon schätzen): OF-01/OF-02 (durch v1.3 beantwortet), OF-73 (X-3a/X-3b-Migration), Albuminkorrekturformel Calcium (neu, ohne OF-Nummer), funktionelle Zielbereiche E-9 (Zahlen fehlen trotz Entscheidung), OF-46 (Eskalationsfrist), OF-47 (Reevaluationsfälligkeit), OF-49/OF-68 (Mindestfallzahlen), OF-42 (Schweregrad-Werteraum), OF-38 (leere Warnhinweis-Spalten).

Nicht abschließend verifiziert

Beide Teilanalysen haben die Testsuiten (src/test) nicht gelesen — Aussagen „ist getestet" wurden deshalb vermieden. praxis01-referenzfall-02.json wurde nicht Feld für Feld gegen alle FACH-115-Kriterien geprüft, nur gegen Struktur und Loader-Verhalten. zwirn-feedback-service wurde nur über Repo-Dokumentation beurteilt (FACH-099), nicht gegen den Zwirn-Code selbst. Ob E-7 inhaltlich ausreicht, um E2 tatsächlich zu bauen (nicht nur, ob der Ausschlussgrund entfällt), ist eine fachliche Wertung, die dieses Dokument bewusst nicht trifft — das ist die eigentliche Scope-Entscheidung aus Stufe 0.

Zurückgestellt (2026-08-26)

Der Product Owner hat entschieden, die hier analysierten Epics nicht weiterzuverfolgen: der Fokus liegt auf einem schnell vorführbaren ersten Prototyp (der bereits gebaute Sechs-Schritt-Gold-Path), nicht auf den Scope-Erweiterungen dieses Dokuments — allen voran der Wiedereinführung von Ebene E2, den molaren Umrechnungsfaktoren (FACH-037) und dem R-Praxis-Rückkanal.

Zurückgestellt, nicht verworfen. Die Analyse bleibt vollständig stehen; die beiden Stufe-0-Befunde (Provenienz von referenzfaelle/, Scope-Entscheidung E2) sind damit nicht beantwortet, sondern nur nicht mehr terminiert. Eine spätere Wiederaufnahme beginnt unverändert bei ihnen. Die fünf Leitplanken aus CLAUDE.md, die ADR-Kette und die zwei externen offenen Fragen (Regulatorik, Pilot-Betriebsmodus) sind von dieser Priorisierung unberührt — sie sind Architekturentscheidungen, keine Feature-Reihenfolge.