# Sprint 7C-E – Laborbestand und Datengranularität

Stand: 2026-08-19, verbindliche Basis `96df2a255dcfb73ea56257997a15e64d58824d64`.

## Preflight

- Lokaler `HEAD` und frisch authentisiert geladener `origin/main` entsprechen exakt der Basis; der Arbeitsbaum war sauber.
- Die private V5-Runtime nennt exakt diesen Commit (`v5-96df2a255dcf`); alle 113 installierten Runtime-Dateien unter `scripts/health` sind bytegleich mit Git.
- V4 ist byteidentisch mit dem geschützten SHA-256 `798d11f191b402c556ec9233f50f5622d7f849022ff301cb4336ef2556e5f3a8`.
- `health-dashboard.service` und `health-dashboard-action-worker.path` sind aktiv und aktiviert; die Action-Inbox enthielt weder offene noch verarbeitende oder fehlgeschlagene Aktionen.
- V4 liefert privat HTTP 200. V5 liefert ohne Authentisierung 401 und authentisiert HTTP 200. Source-Status, bestehende Laborhistorie und Dokumentprüfungs-Queue liefern authentisiert HTTP 200 mit `no-store` und `nosniff`.
- SQLite `integrity_check=ok`; Foreign-Key-Prüfung ohne Befund.
- Bestehende Labor-/Dokument-/Review-Vertragstests: 34 bestanden. Bestehende isolierte V5-Browsergruppe 7C-D: 7 bestanden, ausschließlich synthetische Daten.
- Das private Weiterentwicklungskonzept wurde über die autorisierte Drive-Quelle geprüft. Es bestätigt die Trennung von verifizierten Daten und ungeprüften Kandidaten sowie die bestehenden privaten Queue-Sicherheitsgrenzen.

## Verwendungszweck und Datengranularität

Ein Laborresultat ist genau **eine dokumentierte Beobachtung**:

- ein Laborparameter;
- ein Untersuchungszeitpunkt beziehungsweise Befundtag;
- ein originaler Wert oder qualitativer Befund;
- eine originale Einheit, sofern dokumentiert;
- ein untersuchungs- und quellenspezifischer Referenzbereich, sofern dokumentiert;
- eine konkrete Quelle beziehungsweise ein konkretes Dokument;
- ein fachlicher Reviewstatus.

Untersuchungs-/Befunddatum, Dokumentdatum, Importdatum und Bestätigungsdatum bleiben getrennte Felder beziehungsweise Ereignisse. Fehlende Daten bleiben unbekannt. Technische Match-Confidence und fachlicher Reviewstatus sind voneinander unabhängig. Weder ein hoher Matchwert noch ein vorhandener Katalogtreffer erzeugt automatisch eine Bestätigung.

## Bestehende Tabellen und Verträge

Die Bestandsaufnahme verwendet ausschließlich vorhandene Verträge:

- `laborwerte`: kanonische Laborbeobachtungen; V5 veröffentlicht nur die bestehende streng geprüfte Teilmenge.
- `laborwerte_staging`: vorhandene Import-/Excel-/OCR-Stagingfläche; aktuell leer.
- `document_candidates`: extrahierte Dokumentkandidaten samt Rohwert, Einheit, Seite, Kontext, technischer Confidence, Kandidatenrevision und Reviewstatus.
- `document_candidate_matches`: technischer Katalog-/Bestandsabgleich mit Matchstatus, normalisiertem Parameter/Datum/Wert/Einheit, Referenztext und Vergleichsdigest.
- `document_candidate_review_events`: append-only Reviewereignisse.
- `document_transfer_staging`: unveränderliche Transfer-Vorschau mit Text-, Kandidaten- und Reconciliation-Revision sowie Idempotenzschlüssel.
- `document_processing`, `document_reconciliation`: Dokument- und Queuezustand.
- `document_review_log`: deterministischer Aktionsbeleg und Replay-Schutz.
- private Action-Inbox, Session-, Origin- und Einmal-CSRF-Vertrag des bestehenden Servers;
- idempotenter Action-Worker mit einer SQLite-Transaktion pro Review-/Transferaktion;
- `LAB_ALLOWLIST` und `LAB_CATALOG_SPECS`: bestehender freigegebener V5-Laborkatalog.

Es wird keine zweite Labor-Datenwahrheit aufgebaut. Die vorhandene revisionsgebundene Review → Vorschau → separater Transfer-Kette trägt den Kern der kontrollierten Bestätigung migrationsfrei. Neue DDL ist für diesen Sprint nicht vorgesehen.

## Read-only Bestand

Die folgenden Zahlen stammen aus einer SQLite-Verbindung mit URI `mode=ro` und `PRAGMA query_only=ON`. Es wurden keine Parameterbezeichnungen, Messwerte, Dokumentnamen, Pfade oder sonstigen medizinischen Rohinhalte protokolliert.

### Kanonische und bestätigte Laborwerte

| Kennzahl | Bestand |
|---|---:|
| Zeilen in `laborwerte` | 480 |
| fachlich validiert und gegen Original bestätigt | 120 |
| unterschiedliche bestätigte Rohparameter | 59 |
| unterschiedliche dokumentierte Einheiten | 22 |
| frühester bestätigter Befundtag | 2025-05-13 |
| letzter bestätigter Befundtag | 2026-06-09 |
| bestätigte Werte mit dokumentiertem Referenzbereich | 111 |
| bestätigte Werte ohne dokumentierten Referenzbereich | 9 |
| unterschiedliche Quellbezeichnungen | 2 |
| unterschiedliche Quelltypen | 1 |
| eindeutig verknüpfte Quelldokumente | 11 |

„Bestätigt“ bedeutet hier ausschließlich: `validierungsstatus='validiert'` und `verified_against_original=1`. Es ist keine Aussage über medizinische Vollständigkeit.

### Bestätigte Laborabdeckung in V5

Der bestehende V5-Vertrag verlangt zusätzlich einen originalbezogenen Referenzquellenvertrag, eine dokumentierte Einheit, einen freigegebenen Katalogtreffer, einen Befundtag, einen eindeutigen Tageswert und einen als endliche Zahl freigabefähigen Wert.

| Kennzahl | Bestand |
|---|---:|
| katalogisierte, datierte bestätigte Zeilen vor Werteformat-Gate | 20 |
| aktuell in Laborhistorie/Explorer sichtbare bestätigte Messwerte | 19 |
| sichtbare bestätigte Parameter | 6 |
| Parameter mit mehreren bestätigten Zeitpunkten | 4 |
| Parameter mit genau einem bestätigten Zeitpunkt | 2 |
| bestätigte Zeilen außerhalb des aktuellen V5-Katalogs | 100 |
| bestätigte Rohparameter ohne aktuelle thematische Kataloggruppe | 53 |
| katalogisierte Zeilen mit nicht als einfache endliche Zahl freigegebenem Werteformat | 1 |

Die Abdeckung heißt ausdrücklich **„Bestätigte Laborabdeckung“**, nicht „medizinisch vollständig“. Nicht klassifizierte Parameter bleiben in der Abdeckungsbilanz sichtbar, werden aber nicht frei medizinisch interpretiert.

### Kandidatenbestand

| Kennzahl | Dokument-/OCR-Kandidaten | Import-/Excel-Staging |
|---|---:|---:|
| Kandidaten gesamt | 9 | 0 |
| offen | 9 | 0 |
| Konflikt oder mehrdeutiger Abgleich | 2 | 0 |
| mögliches Duplikat beziehungsweise vorhandener Vergleichstreffer | 2 | 0 |
| ohne Befunddatum | 0 | 0 |
| ohne Einheit | 0 | 0 |
| ohne sicheren bestehenden Katalogtreffer | 7 | 0 |

Das vorhandene `laborwerte_staging` enthält zum Stichtag weder OCR-, Excel- noch sonstige offene Importkandidaten. Die neun vorhandenen Kandidaten stammen aus dem bestehenden Dokument-/Extraktionsvertrag. Die Bestandszahlen sind technisch und nicht medizinisch wertend.

## Reproduzierbare Zählregeln

1. Datenbank ausschließlich als `file:…?mode=ro` öffnen und `PRAGMA query_only=ON` setzen.
2. Integrität mit `PRAGMA integrity_check` und `PRAGMA foreign_key_check` prüfen.
3. Bestätigte Rohwerte mit `lower(trim(COALESCE(validierungsstatus,'')))='validiert' AND verified_against_original=1` zählen.
4. V5-Abdeckung zusätzlich mit `reference_range_source='scanned_original'`, Befundtag, bestehendem `LAB_ALLOWLIST`-Parameter und dem bestehenden Werteformat-/Eindeutigkeitsvertrag bestimmen. Eine Einheit ist für numerische Werte Pflicht; allowlist-begrenzte qualitative Befunde bleiben ohne erfundene Einheit als Text erhalten.
5. Dokumentkandidaten auf `candidate_type='laboratory_value'` begrenzen. Offen sind ausschließlich `open` und `conflicting`.
6. Konflikte aus fachlichem Kandidatenstatus sowie technischem `value_conflict`/`ambiguous` ableiten; Confidence separat zählen und niemals als Reviewstatus verwenden.
7. Mögliche Duplikate aus `exact_match`, `format_unit_match`, `repeated_exact` oder einem vorhandenen kanonischen Vergleichstreffer ableiten; niemals still zusammenführen oder löschen.
8. Fehlendes Datum und fehlende Einheit als eigene Unknown-Dimensionen zählen.
9. Katalogabdeckung ausschließlich gegen den bestehenden lokalen Katalog prüfen; keine externen oder frei geratenen medizinischen Zuordnungen ergänzen.
10. Vor und nach jeder realen read-only Inventur DB-Digest beziehungsweise Integrität vergleichen; keine Rohinhalte in Logs oder versionierte Evidenz schreiben.

## Thematische Gruppierungsgrenze

Der bestehende Katalog besitzt noch kein explizites, reviewtes Feld für thematische Präsentationsgruppen. Deshalb bleiben auch katalogisierte Parameter in diesem Sprint sichtbar unter „Weitere / nicht klassifiziert“. Die gewünschten Gruppen werden erst belegt, wenn der bestehende Katalog ausdrücklich um eine versionierte Gruppenbelegung erweitert wird; eine Gruppierung anhand von Namen oder medizinischer Interpretation findet nicht statt.

## Ausdrücklich nicht automatisch bestätigt

- alle neun Dokument-/OCR-Kandidaten;
- alle technischen Katalogvorschläge unabhängig von ihrer Confidence;
- alle Konflikte und möglichen Duplikate;
- alle unlesbaren, unplausiblen oder unvollständigen Werte;
- alle Excel-/Importplanwerte ohne Originalprüfung;
- alle Werte ohne separate ausdrückliche Preview- und Confirm-Aktion.