konzept vertraulich owner: matus

Domain-Map

Domain-Map

Key: PG-DOMAINS-0002 · Domain: Projekt · siehe ../INDEX.md

Die acht Domänen des Fachmaterials und ihre Abbildung in diesem Prototyp. Die Modulkürzel des Materials sind nicht übernommen (Begründung in ADR-0001 Punkt 2), die Objektkürzel schon.

#	Domäne (Material)	Im Prototyp	Objekte
1	Klinisches Regelwerk	Teilweise — als regelwerk/Regelkatalog.java, nicht als Domäne	Konstanten mit Fundstelle; FACH-119 nur als mitgeführtes Feld
2	Patient & Fall	Ja	Patient (txm-pat), Sicherheitsmerkmal (txm-sim), Auswertung (txm-aus)
3	Intake & Befund	Ja	Messwert (txm-msw), Medikationseintrag (txm-med), Supplementeintrag (txm-sup)
4	Auswertung	Teilweise — E1 und E3, kein E2	Finding (txm-fnd)
5	Evidenz & Research	Nein — nur die Evidenzkennzeichnung an Findings/Empfehlungen	Quellenklasse, Evidenzgrad als Attribute
6	Therapieplan & Freigabe	Ja	Empfehlung (txm-rec), Therapeutenentscheidung (txm-ent), Uebersteuerung (txm-ovr), Freigabe als Feldgruppe
7	Bericht	Teilweise — nur Therapeutenversion, als Projektion	Bericht, Berichtsabschnitt (keine Entität)
8	Klinische Governance & Pilotsteuerung	Nein — außer dem Systemsteckbrief	Systemsteckbrief (= Einschränkungsdokumentation, FACH-118)

Business-Key-Format

{tenant}-txm-{objekt}-{nanoid8} nach GG-GOV-GDPR-0001.1. Der nanoid8-Teil entsteht serverseitig und wird nie erfunden.

Beispiel: praxis01-txm-aus-ab12cd34 — das ist zugleich die im UI sichtbare Auswertungsreferenz (FACH-013 verlangt „eindeutig und sichtbar").

Mandant = Praxis — mit einem offenen Widerspruch

Der Mandant ist fachlich die Praxis; rollen.md führt dafür fünf unabhängige Belege. GM-6 formuliert allerdings „die jeweilige Praxis bzw. der jeweilige Therapeut" und lässt damit beides offen (OF-12).

Davon hängt ab: Sieht Therapeut B die Patienten von Therapeut A? Wessen Regelversion steht im Bericht, wenn beide in derselben Praxis arbeiten? Zählt eine Übersteuerung durch A in die Kennzahlen der Praxis oder in die von A?

Ein Prototyp mit einer Praxis und einem Therapeuten kann die Frage umgehen; die erste Praxis mit zwei Therapeuten kann es nicht. Es gibt hier deshalb keine Ebene unterhalb des Tenants — sie zu erfinden wäre die Vorentscheidung.

Was das Material ausdrücklich NICHT getrennt haben will

Vier Anti-Anforderungen, die ein Entwurf leicht verletzt:

Nicht trennen	Fundstelle
Kontraindikationen und dauerhafte Sicherheitsmerkmale — „eine einzige fachliche Quelle. Es gibt keine zwei getrennt gepflegten Listen"	FACH-044, Z. 1043
Einschränkungsdokumentation und Systemsteckbrief — „identisch gepflegt. Es gibt keine zweite Liste"	FACH-118, Z. 2050
„Nicht verwertbare Angaben" und „nicht abgedeckte Parameter" — „deckungsgleich"	FACH-047, Z. 1102
„Sicherheitsebene E1" als eigene Domäne — sie ist ein Attribut von Findings, keine Datenhoheit	GM-4, Z. 131

Alle vier sind im Modell eingehalten: ein Kontraindikation-Katalog, ein Systemsteckbrief, ein Berichtsabschnitt „Nicht verwertete Angaben", ein Ebene-Attribut am Finding.

Datenklassifizierung im Frontend: [ST] / [PK] / [PR] / [PK→PR]

Vier Datenklassen, die entscheiden, wo ein Datum gepflegt wird, wer es ändern darf, ob eine Änderung rückwirkt und ob es versioniert werden muss. Übernommen aus einer externen Frontend-Spezifikation (Review: ../../agentic-engineering/backlog/frontend-spezifikation-v1-review.md) - sie formalisiert nur, was oben bereits gilt, ohne es bisher zu benennen.

Marker	Klasse	Entspricht hier	Lebensdauer	Änderung wirkt
[ST]	Stammdaten	regelwerk/Regelkatalog.java, Kontraindikation, RedFlag - fallunabhängig, versioniert nach FACH-119	dauerhaft, versioniert	nicht rückwirkend auf freigegebene Fälle
[PK]	Patientenkontext	Patient-Basisdatensatz, Sicherheitsmerkmal - patientenbezogen, fallübergreifend, klinisch wirksam	dauerhaft je Patient, mit Erhebungsdatum	auf künftige Fälle; laufender Fall nur nach Bestätigung
[PR]	Prozessdaten	Messwert, Finding, Empfehlung, Freigabe - alles, was im Auswertungslauf entsteht	je Auswertung	nur innerhalb des Falls, nach Freigabe unveränderlich
[PK→PR]	Momentaufnahme	die basis*-Spalten an AuswertungEntity (FACH-013, Z. 443)	je Auswertung	keine Rückwirkung

Vier Prüffragen für jedes neue Feld:

1. Gilt die Angabe unabhängig von diesem Patienten? Ja → [ST].
2. Gilt sie für den Patienten über Fälle hinweg und verändert sie die fachliche Bewertung? Ja → [PK], mit Erhebungsdatum und Bestätigungslogik (siehe FACH-017).
3. Entsteht sie im Vorgang und beschreibt sie diesen Fall? Ja → [PR].
4. Würde eine spätere Änderung einen freigegebenen Fall verändern? Falls ja, ist die Klassifizierung falsch - [ST] braucht Versionierung, [PK] braucht eine Momentaufnahme.

Kennzeichnungspflicht im UI (aus derselben Quelle, hier noch nicht umgesetzt): jedes Feld, das aus [ST] oder [PK] stammt, sollte im Fallkontext als übernommen erkennbar sein - mit Herkunft, Version bzw. Erhebungsdatum und einem Sprung zur Pflegestelle. Ein Nutzer soll nie im Zweifel sein, ob er gerade einen Fall oder einen Katalog bearbeitet.