konzept vertraulich owner: matus

Studien/Quellen-Verlinkung im Regelwerk — Konzept statt Mockup-Feature (Nutzervorgabe 2026-08-26)

Status: Konzept, ungebaut. Der Nutzer hat gebeten, jeden Bezug auf "Stories" zu entfernen und stattdessen ein Konzept dafür zu liefern, wie tuxametrics mit Studien umgeht und ob sie sich verlinken lassen — Beispielformat "Basiert auf Studie XYZ".

Herkunft

Im Repo selbst gibt es keine einzige Stelle (Frontend-Code, Backend-Code, Dokumentation), die das englische Wort "Stories" trägt — geprüft per Volltextsuche über tuxametrics-ui/src, tuxametrics-laborauswertung-service/src und documentation/. "Stories" im engeren Sinn (Agile/Scrum-User-Stories) taucht nur zweimal in internen Engineering-Dokumenten auf (documentation/fachlich-beschrieben-nicht-gebaut.md, documentation/domain/regelwerk-governance.md) und meint dort etwas anderes: unbewertete User-Stories aus dem Quellmaterial, kein UI-Element.

Was es dagegen gibt: TODO-raw/Simplyfied Tuxametrics 1/TuxAmetrics Wireframes.html (Hi-Fi-Mockup) zeigt auf der Regel-Detailseite einen Abschnitt mit dem Titel "Aus dem Internet recherchiert" / "Externe Studien und Leitlinien — Suche vom 12.08.2026, 14:02", gefüllt mit einem Beispiel:

Selenstatus bei akuter Entzündung Kohortenstudie · European Journal of Clinical Nutrition · 2021

Das ist vermutlich gemeint, wenn von "Stories" die Rede war — eine Verwechslung mit "Studies", die im Mockup tatsächlich als automatisch internetrecherchierte Studienkarten auftauchen. Dieser Abschnitt ist in keinem Screen dieses Repos umgesetzt — es gibt nichts, das man aus dem Live-Produkt entfernen müsste.

Warum das Mockup so nicht gebaut werden sollte

Die Leitregel dieses Projekts (CLAUDE.md) lautet: "Wo das Material keine Zahl hat, hat der Code auch keine." Dieselbe Disziplin gilt für Quellenangaben, nicht nur für Zahlen:

"Aus dem Internet recherchiert" behauptet eine Autorität, die niemand geprüft hat. Eine Suche, die zur Laufzeit (oder von einem Agenten beim Bauen) irgendeine Studie findet, sagt nichts darüber, ob sie tatsächlich die im Regelwerk hinterlegte Zahl stützt, methodisch tragfähig ist oder noch aktuell ist. Das Mockup-Beispiel ("Selenstatus bei akuter Entzündung", 2021) hat keinen erkennbaren Bezug zu einer konkreten Regel dieses Katalogs — es ist Bildschirmdekoration, keine Beleglage.
Es gibt kein Modell für Evidenzgrad in diesem Repo — bewusst. ADR-0011 ("Bewusst offen gelassen") benennt das ausdrücklich: "Evidenzgrad I-1 bis I-3 je Regel. FACH-061 verlangt ihn. Welcher Grad wann gilt, sagt das Material nicht — er würde geraten." Eine automatisch eingeblendete Studienkarte ohne Evidenzgrad-Einordnung wäre fachlich weniger als das, was das Material selbst schon als unzureichend verwirft.
Regulatorisch heikel. tuxametrics.regulatorik.einstufung steht laut ADR-0002 bewusst auf UNGEKLAERT. Eine Oberfläche, die ungeprüfte externe Quellen neben einer Therapieempfehlung präsentiert, sieht nach klinischer Evidenzbasis aus, ohne eine zu sein — das ist genau die Art Anspruch, die dieses Repo an anderer Stelle konsequent vermeidet (GM-6.2: "eine praxiseigene Regel nie als allgemeingültige fachliche Grundlage dargestellt").

Vorschlag: ein Quellenfeld, das eine Person füllt — kein automatisierter Studien-Fetch

Statt einer recherchierten Studienkarte: ein optionales Freitextfeld "Quelle", das eine Praxis beim Setzen eines eigenen Regelwerts (R-Praxis, RegelWertPanel) neben der bereits vorhandenen Pflicht-Begründung ausfüllen kann — Beispielwert genau im vom Nutzer skizzierten Format: "Basiert auf Studie XYZ", oder ausführlicher mit Titel/Jahr/DOI, ganz wie bei der Begründung selbst freie Formulierung.

Warum das dieselbe Disziplin einhält wie der Rest des Repos:

Die Quelle ist eine Behauptung der Praxis, keine Systemaussage — exakt dieselbe Rolle wie die bereits vorhandene Pflichtbegründung (FACH-061: "Je Regel sind Anlass, fachliche Begründung … und verantwortliche Person dokumentiert"). Das System sucht nichts, prüft nichts, bewertet nichts — es speichert und zeigt, wortwörtlich wie eingegeben.
Erscheint an denselben zwei Stellen wie die Begründung: im RegelWertPanel beim Setzen/Ändern eines Werts, und je Eintrag in RegelVerlaufListe (Änderungsverlauf) — damit bleibt nachvollziehbar, welche Quelle zu welcher konkreten Änderung gehörte, nicht nur zum aktuellen Stand.
Passt in die bestehende RegelwertSetzen/Regelaenderung-Struktur als ein zusätzliches optionales Feld (quelle: string | null), keine neue Entität.

Was das ausdrücklich NICHT ist:

Keine automatisierte Internetsuche, kein KI-generierter Studienvorschlag.
Keine Verifikation, ob die genannte Quelle den gesetzten Wert tatsächlich stützt — das bleibt Aufgabe der Person, die die Begründung schreibt, wie bei der Begründung selbst auch.
Kein Evidenzgrad, keine Studienqualitäts-Einstufung (siehe ADR-0011, weiterhin bewusst offen).
Kein Pflichtfeld — die meisten Regeländerungen in der Praxis werden auf klinischer Erfahrung beruhen, nicht auf einer zitierfähigen Einzelstudie, und sollen das auch bleiben dürfen.

Was es bräuchte, wenn entschieden

Backend: RegelwertSetzen/RegelwertZuruecksetzen (oder eine neue, gemeinsame Struktur) um ein optionales quelle-Feld erweitern; RegelwertEntity/Regelaenderung-Persistenz entsprechend.
Frontend: ein weiteres, optionales Textfeld im Bearbeiten-Formular von RegelWertPanel.tsx (neben der Begründung), Anzeige in RegelVerlaufListe.tsx und im "Begründung der Praxis"-Block von RegelWertPanel.tsx.
Keine Fachentscheidung über was eine gültige Quelle ist — reines Freitextfeld, keine Validierung, kein Format-Zwang (URL, DOI, Klartext-Zitat — alles zulässig).

Kein Aufwand an anderer Stelle: keine neue Capability (läuft unter dem bestehenden txm.regelwerk.regel.aendern), keine neue Route, keine neue Domäne.