01 / Problème
Une vue de monitoring n’est utile que si ses données gardent leur contexte.
Les mesures ne sont pas de simples nombres isolés. Une application clinique doit conserver patient, encounter, code, unité, moment et source avec chaque valeur—tout en contrôlant l’accès aux données sous-jacentes.
- Mesures structurées dans le temps
- Contexte Patient et Encounter
- Frontières interopérables plutôt qu’un modèle réduit à l’export
02 / Architecture
FHIR se trouve dans le système, pas seulement à sa sortie.
Le stack implémenté utilise FHIR comme contrat actif entre UI clinique React, BFF/API FastAPI, serveur HAPI FHIR interne et PostgreSQL. Le navigateur ne devient pas un client d’intégration non contrôlé.
- 01React / TypeScriptPrésentation frontend clinique
- 02Gateway same-originNginx fournit UI, /api et /auth
- 03FastAPI BFF / APIContrats cliniques validésimplémenté
- 04Keycloak + RedisOIDC, session serveur chiffréeimplémenté
- 05Intégration FHIRAccès REST et mapping contrôlés
- 06HAPI FHIR R4Serveur de ressources cliniques interneimplémenté
- 07PostgreSQLCouche de persistance HAPIimplémenté
03 / Flux de données
Un chemin traçable des mesures à la vue de monitoring.
Les FHIR Observations apportent la base structurée des séries temporelles et de la visualisation. L’architecture ne fabrique volontairement aucune recommandation : la sortie est une vue technique de monitoring, pas une aide à la décision clinique.
- 01FHIR Observations
- 02Frontière de requête validée
- 03Série temporelle
- 04Traitement de tendance
- 05Vue de monitoring clinique
Le monitoring peut afficher une tendance. Il ne remplace pas l’évaluation clinique et ne formule pas de recommandation.
04 / Modèle de données cliniques
Identité et Encounter ancrent chaque Observation.
L’identité stable inter-systèmes commence par un système d’identifiant et une valeur, pas par une correspondance nom-date de naissance. Le contexte Encounter permet de comprendre où se situe une mesure dans le parcours de soins.
Patient.identifier système + valeur → Patient → Encounter → Observation
- Fréquence cardiaque
- LOINC 8867-4
- Panel tension artérielle
- LOINC 85354-9
- Systolique / diastolique
- 8480-6 / 8462-4
- Température corporelle
- LOINC 8310-5
Le code et les références subject et encounter précisent ce qui est mesuré et dans quel contexte de soins. Unités et valeurs doivent respecter les règles de profil et de qualité du système destinataire.
{
"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 / Interopérabilité
Le monitoring clinique a besoin de relations, pas d’un catalogue de ressources.
L’ensemble de ressources pertinent dépend du périmètre clinique. Les Observations alimentent les vues de mesure ; Patient et Encounter établissent identité et contexte ; ressources documentaires et de planification ne deviennent pertinentes que lorsqu’un workflow le demande.
Patient
Porte une identité stable par système d’identifiant + valeur.
Encounter
Relie les Observations à l’épisode ou contexte de soins.
Observation
Représente mesures codées, unités, temporalité et références.
Composition
Concept possible de documentation infirmière structurée.
CarePlan / RiskAssessment
Concepts de workflow futurs, pas un moteur de recommandation revendiqué.
FHIR / terminologyDes codes LOINC sont montrés pour les constantes courantes. SNOMED CT et UCUM restent des sujets terminologiques nécessitant jeux de valeurs approuvés, règles de profils et gouvernance dans une implémentation réelle.
06 / Sécurité
Les frontières de confiance rendent les intégrations contrôlables.
L’implémentation conserve HAPI FHIR et les deux bases de données dans des réseaux Docker internes. Le BFF détient des sessions OAuth chiffrées côté serveur ; le backend vérifie signature, issuer, audience, client autorisé, type de token et rôles avant tout accès clinique.
Navigateur
Utilise /auth et /api en same-origin ; ne reçoit ni tokens OAuth ni credentials FHIR sans restriction.
Fournisseur d’identité
Keycloak fournit OIDC Authorization Code + PKCE avec sessions liées à state, nonce et CSRF.
Backend
Valide les requêtes et applique le moindre privilège : pflege_read, pflege_write, pflege_delete et pflege_admin.
Serveur FHIR
Reçoit des requêtes contraintes depuis l’API et n’est pas publié sur un port hôte.
Le dépôt documente des contrôles implémentés ; test de pénétration externe et approbation clinique restent hors du périmètre démontré.
07 / Décisions d’ingénierie
Décisions d’ingénierie clés
- 01
FHIR comme contrat système
FHIR demeure sur le chemin actif de l’intégration plutôt qu’un format d’export final.
- 02
Le contexte clinique voyage avec la valeur
Les mesures sont ancrées dans Patient et Encounter afin que les séries ne soient pas décontextualisées.
- 03
Moindre privilège dans le backend
Identité, autorisation et accès FHIR contrôlé restent séparés du frontend.
- Choisir profils et patterns de requêtes qui préservent le sens clinique sans surcharger les données.
- Afficher mesures tardives, manquantes ou contradictoires sans masquer les problèmes de qualité.
- Distinguer vue technique de tendance et conseil clinique, dans l’UX comme dans la gouvernance produit.
08 / État & suite
État actuel
DÉMONSTRATION IMPLÉMENTÉELe dépôt implémente React/Vite, FastAPI, HAPI FHIR R4, PostgreSQL, Keycloak, des sessions BFF chiffrées soutenues par Redis, une gateway interop versionnée, l’admission Patient/Encounter, des écritures cliniques contrôlées, tendances et un seeding de démonstration synthétique.
DIRECTION FUTURE
Direction future
Il reste la gouvernance des profils et terminologies, le mode production TLS/Keycloak, une couverture no-store explicite des GET cliniques, une revue de sécurité externe et une validation clinique. Le mode ML synthétique demeure volontairement non clinique.
09 / Ce que cela démontre
Ce que ce projet démontre
- 01Conception full-stack de frontières pour systèmes cliniques
- 02Relations de ressources FHIR R4 et contexte clinique
- 03Architecture API et autorisation sensible à la sécurité
- 04Chemin de données pour des analyses futures explicables, sans théâtre IA