01 / Problem
Eine Monitoring-Ansicht ist nur so nützlich wie ihr Datenkontext.
Messwerte sind keine isolierten Zahlen. Eine klinische Anwendung muss Patient, Encounter, Code, Einheit, Zeitpunkt und Quelle mit dem Wert erhalten—und dabei Zugriff auf die zugrunde liegenden Daten kontrollieren.
- Strukturierte Messungen über die Zeit
- Patienten- und Encounter-Kontext
- Interoperable Grenzen statt Export-only-Modell
02 / Architektur
FHIR liegt im System, nicht nur an seinem Rand.
Der implementierte Stack behandelt FHIR als aktiven Vertrag zwischen React-Frontend, FastAPI-BFF/API, internem HAPI-FHIR-Server und PostgreSQL. Der Browser wird nicht zum unkontrollierten Integrationsclient.
- 01React / TypeScriptKlinische Frontend-Darstellung
- 02Same-Origin-GatewayNginx liefert UI, /api und /auth
- 03FastAPI BFF / APIValidierte klinische Verträgeimplementiert
- 04Keycloak + RedisOIDC, verschlüsselte Server-Sessionimplementiert
- 05FHIR-IntegrationKontrollierter REST-Zugang und Mapping
- 06HAPI FHIR R4Interner klinischer Ressourcenserverimplementiert
- 07PostgreSQLHAPI-Persistenzschichtimplementiert
03 / Datenfluss
Ein nachvollziehbarer Pfad von Messungen zur Monitoring-Ansicht.
Serverseitig gemappte FHIR Observations bilden die strukturierte Basis für patientenbezogene Trends und fachlich lesbare Details. Die optionale ML-Simulation ist standardmäßig deaktiviert und klar als synthetisch, preliminary und nicht klinisch validiert markiert.
- 01FHIR Observations
- 02Validierte API- / Abfragegrenze
- 03FHIR-Mapper
- 04Zeitreihe
- 05Klinische Monitoring-Ansicht
Monitoring kann einen Trend zeigen. Es ersetzt keine klinische Beurteilung und gibt keine Empfehlung.
04 / Klinisches Datenmodell
Identität und Encounter verankern jede Observation.
Stabile systemübergreifende Identität beginnt mit Identifier-System und Identifier-Wert, nicht mit dem Matching von Name und Geburtsdatum. Encounter-Kontext zeigt, wohin eine Messung im Versorgungsverlauf gehört.
Patient.identifier System + Wert → Patient → Encounter → Observation
- Herzfrequenz
- LOINC 8867-4
- Blutdruck-Panel
- LOINC 85354-9
- Systolisch / diastolisch
- 8480-6 / 8462-4
- Körpertemperatur
- LOINC 8310-5
Code, Subject- und Encounter-Referenz beschreiben, was gemessen wurde und in welchem Versorgungszusammenhang. Einheiten und Werte müssen Profil- und Datenqualitätsregeln des Zielsystems erfüllen.
{
"resourceType": "Observation",
"status": "final",
"code": {
"coding": [{ "system": "http://loinc.org", "code": "8867-4" }]
},
"subject": { "reference": "Patient/synthetic-1042" },
"encounter": { "reference": "Encounter/synthetic-enc-37" }
}05 / Interoperabilität
Klinisches Monitoring braucht Beziehungen, keinen Ressourcenkatalog.
Die relevante Ressourcenmenge folgt dem klinischen Scope. Observations treiben Messansichten; Patient und Encounter schaffen Identität und Kontext; Dokumentations- und Planungsressourcen werden erst relevant, wenn ein Workflow es erfordert.
Patient
Trägt stabile Identität über Identifier-System + Identifier-Wert.
Encounter
Verbindet Observations mit Episode oder Versorgungskontext.
Observation
Repräsentiert codierte Messungen, Einheiten, Zeitpunkt und Referenzen.
Composition
Mögliches Konzept für strukturierte pflegerische Dokumentation.
CarePlan / RiskAssessment
Zukünftige Workflow-Konzepte, keine behauptete Empfehlung-Engine.
FHIR / terminologyLOINC-Codes sind für gängige Vitalzeichen gezeigt. SNOMED CT und UCUM bleiben Terminologie-Themen, die in einer realen Implementierung freigegebene Value Sets, Profilregeln und Governance brauchen.
06 / Sicherheit
Trust Boundaries machen Integration kontrollierbar.
Die Implementierung hält HAPI FHIR und beide Datenbanken in internen Docker-Netzen. Das BFF hält verschlüsselte serverseitige OAuth-Sessions; das Backend prüft vor klinischem Zugriff Signatur, Issuer, Audience, autorisierten Client, Token-Typ und Rollen.
Browser
Nutzt Same-Origin /auth und /api; erhält weder OAuth-Tokens noch uneingeschränkte FHIR-Credentials.
Identity Provider
Keycloak liefert OIDC Authorization Code + PKCE mit state-, nonce- und CSRF-gebundenen Sessions.
Backend
Validiert Anfragen und erzwingt Least Privilege: pflege_read, pflege_write, pflege_delete und pflege_admin.
FHIR Server
Erhält eingeschränkte Anfragen aus der API und ist nicht über einen Host-Port veröffentlicht.
Das Repository dokumentiert implementierte Kontrollen; externe Penetrationstests und klinische Freigabe liegen außerhalb des gezeigten Umfangs.
07 / Engineering-Entscheidungen
Zentrale Engineering-Entscheidungen
- 01
FHIR als Systemvertrag
FHIR bleibt im aktiven Integrationspfad und ist nicht erst ein nachgelagertes Exportformat.
- 02
Klinischer Kontext reist mit dem Wert
Messungen werden in Patient- und Encounter-Referenzen verankert, damit Zeitreihen nicht kontextlos werden.
- 03
Least Privilege im Backend
Identität, Autorisierung und kontrollierter FHIR-Zugang bleiben vom Frontend getrennt.
- Profile und Abfragemuster auswählen, die klinische Bedeutung bewahren ohne Daten zu weit zu laden.
- Verspätete, fehlende oder widersprüchliche Messungen zeigen, ohne Datenqualitätsprobleme zu verstecken.
- Technische Trendanzeige und klinische Anleitung in UX und Product Governance klar trennen.
08 / Stand & Ausblick
Aktueller Stand
IMPLEMENTIERTE DEMODas Repository implementiert React/Vite, FastAPI, HAPI FHIR R4, PostgreSQL, Keycloak, Redis-gestützte verschlüsselte BFF-Sessions, ein versioniertes Interop-Gateway, Patient-/Encounter-Aufnahme, kontrollierte klinische Schreibvorgänge, Trends und synthetisches Demo-Seeding.
NÄCHSTE RICHTUNG
Nächste Richtung
Offen sind Profil- und Terminologie-Governance, TLS/Keycloak-Produktionsmodus, explizite no-store-Abdeckung für klinische GET-Antworten, externes Security Review und klinische Validierung. Der synthetische ML-Modus bleibt bewusst nicht-klinisch.
09 / Was dies zeigt
Was dieses Projekt zeigt
- 01Full-Stack-Grenzendesign für klinische Systeme
- 02FHIR-R4-Ressourcenbeziehungen und klinischer Kontext
- 03Sicherheitsbewusste API- und Autorisierungsarchitektur
- 04Ein Datenpfad für nachvollziehbare spätere Analytik statt AI-Theater