adr vertraulich owner: matus

ADR-0002: Der regulatorische Status ist UNGEKLÄRT — externe Klärung ausstehend, und das Produkt sagt es laut

ADR-0002: Der regulatorische Status ist UNGEKLÄRT — externe Klärung ausstehend, und das Produkt sagt es laut

Status

Angenommen (2026-08-09) · Vom Nutzer ausdrücklich als sichtbarer Platzhalter statt einer Annahme gesetzt.

Kontext

Die Frage

tuxamed, Bearbeitet/00-bericht.md, offene Frage OF-B1 (im Material zugleich Entscheidung E-20), wörtlich:

„Klärung, ob TuxAmetrics für den Laborpfad unter die IVDR und für einen künftigen In-vivo-Pfad unter die MDR fällt — vor Formulierung der Zweckbestimmung."

Eingestuft als „sofort anstoßen — lange Vorlaufzeit", Aufwand L, extern abzusichern. Adressat: Product Owner + klinischer Fachexperte, extern (Regulatory/Recht).

Warum sie alles andere überlagert

Der Extraktionsbericht stellt sie vor alle anderen Befunde, mit eigener Überschrift. Der Grund ist eine Spannung im Material selbst: FACH-001 hält als Grundsatzentscheidung fest, dass TuxAmetrics patientenindividuelle Therapievorschläge erzeugt und „nicht auf reine Informationsaufbereitung verengt" wird — „die daraus folgenden Anforderungen sind bekannt und werden nicht implizit umgangen." Zugleich ist die regulatorische Einordnung offen.

Fällt TuxAmetrics unter die EU-Medizinprodukte-Regulatorik, hängen daran Konformitätsbewertung, klinische Bewertung, technische Dokumentation, Risikomanagement, Post-Market-Surveillance und die Frage, wer in welcher Rolle in Verkehr bringt. Nichts davon ist in diesem Prototyp abgebildet — auch nicht ansatzweise.

Der Bericht formuliert die Haltung dazu präzise und sie gilt hier unverändert: „Deshalb steht das hier als Frage und nicht als Annahme. Dieser Bericht trifft dazu keine Aussage, weder beruhigend noch alarmierend."

Ein Restbefund, der dazugehört

Das Material verweist auf ein Dokument „TuxAmetrics — Fachliche Bewertung Hautspektrometrie", das laut Quellzeile eine regulatorische Abwägung enthält. Dieses Dokument liegt nicht in der Ergebniszone (OF-57). Wer OF-B1 klärt, sollte es beschaffen.

Entscheidung

1. Der Status ist UNGEKLAERT und wird nicht durch eine Annahme ersetzt. Weder in Code noch in Konfiguration, weder als Default noch als Kommentar.

2. Er steht als Konstante im Code, nicht als TODO. Das Enum RegulatorischeEinstufung benennt die vier möglichen Antworten (UNGEKLAERT, IVDR, MDR, KEINE-MEDIZINPRODUKTE-REGULATORIK) — damit die offene Frage ihre echten Antwortmöglichkeiten trägt und nicht ein leeres Feld ist.

3. Zur Laufzeit ist ausschließlich UNGEKLAERT zulässig. Jeder andere Wert bricht den Start ab. Durchgesetzt von RegulatorikGuard auf dem Quarkus-StartupEvent, mit einer Fehlermeldung, die die Frage, ihre Herkunft und ihren Adressaten nennt.

   Warum ein Startabbruch und keine Warnung: Wer hier IVDR einträgt, hat nicht die Frage geklärt, sondern ein Feld ausgefüllt. Genau dieser Unterschied verschwindet, wenn das System danach einfach weiterläuft. Eine Warnung im Log ist nach dem dritten Start unsichtbar; ein Startabbruch ist es nie.

4. Sichtbare Umsetzung an fünf Stellen — damit es keine Datei gibt, in der die Frage fehlt:

   • application.properties: tuxametrics.regulatorik.einstufung mit Kommentarblock und Verweis.
   • .env.example und docker-compose.yml: dieselbe Variable, derselbe Verweis.
   • RegulatorikGuard: Startabbruch + WARN-Logzeile bei jedem Start.
   • GET /api/txm/v1/tenants/{tenantKey}/systemsteckbrief: Feld regulatorischeEinstufung samt Hinweistext — abrufbar, nicht nur lesbar.
   • SystemsteckbriefBanner im UI und der Berichtsabschnitt „Systemgrenzen": im Blickfeld des Therapeuten, nicht in einem Menü.

5. Ein Test hält das Gate fest. RegulatorikGuardTest prüft, dass eine eingetragene Einstufung den Start abbricht. Wer die Sperre „nur kurz" entfernt, muss dabei auch einen Test löschen — das ist der Unterschied zwischen einer Entscheidung und einem Versehen.

6. Auflösung nur durch ein Nachfolge-ADR. Liegt die externe Klärung vor, wird dieses ADR auf Superseded gesetzt, das Nachfolge-ADR nennt die externe Fundstelle, und im Zug desselben ADR fällt das Startgate. Nicht umgekehrt.

Konsequenzen

• + Die Frage kann nicht in Vergessenheit geraten. Sie steht in der Konfiguration, im Log, in der API-Antwort, im UI und im Bericht — und sie blockiert den Start, sobald jemand sie stillschweigend beantwortet.
• + Eine Demo dieses Prototyps kann nicht versehentlich den Eindruck erwecken, die regulatorische Frage sei geklärt. Der Systemsteckbrief sagt in derselben Antwort, was der Prototyp beantworten kann und was nicht.
• − Der Guard ist eine ungewöhnliche Startbedingung. Wer den Service in eine Umgebung stellt, in der solche Properties automatisch aus einem Katalog befüllt werden, bekommt einen Startfehler statt eines Defaults. Das ist der Preis und in diesem Fall der Zweck.
• − Das Enum trägt drei Werte, die nie gesetzt werden dürfen. Wer den Code liest, ohne dieses ADR zu kennen, hält sie für Konfigurationsoptionen. Abgemildert durch Javadoc am Enum und die Fehlermeldung des Guards.
• Offen und bewusst nicht entschieden: die Frage selbst. Dieses ADR beantwortet sie nicht — es hält fest, dass sie offen ist, wer sie beantworten muss und was daran hängt.

Nachtrag 2026-08-12: Banner nur noch im Bericht

Status bleibt Angenommen. Geändert hat sich ausschließlich der vierte Spiegelstrich von Entscheidung 4 — die übrigen vier Stellen sind unverändert in Kraft, und der regulatorische Status selbst bleibt UNGEKLAERT mit hartem Startgate.

Auf Wunsch des Product Owners (2026-08-12) zeigt sich SystemsteckbriefBanner in tuxametrics-ui nicht mehr auf jeder Seite über SystemsteckbriefFrame, sondern ausschließlich auf der Berichtsseite (BerichtRoute / BerichtVorschauPage). Der Wunsch kam ohne fachliche Begründung — sie wird hier deshalb nicht nachgereicht, um keine zu erfinden.

Was das schwächt. Der Grund für „im Blickfeld, nicht in einem Menü" oben in diesem ADR gilt unverändert: eine Demo, die nur den Bericht öffnet, sieht den Hinweis; eine, die nur Patienten, Auswertungen oder den Therapieplan zeigt, sieht ihn nicht mehr. Das ist eine bewusste, keine versehentliche Lockerung.

Was unverändert bleibt. Alle anderen vier Stellen aus Entscheidung 4 — application.properties, .env.example/docker-compose.yml, RegulatorikGuard-Startabbruch, GET .../systemsteckbrief — und die eigene Seite /:tenant/systemsteckbrief mit der vollständigen Fassung bleiben bestehen. Der Status ist weiterhin nicht in einem einzigen Dokument versteckt, nur nicht mehr auf jeder Seite der Anwendung selbst.