Conversation complète - local-first, FHIR, stages numérique santé

> Document nettoyé : les blocs de transcript et appels outils ont été retirés pour conserver uniquement les synthèses utiles en Markdown.

Local-first hospitalier face aux pannes longues

1. Le scénario : ce qu'il faut comprendre

Une cyberattaque hospitalière n'est pas une "panne de 3 jours". Le retour d'expérience du **CH d'Armentières** (févr. 2024) est éclairant : urgences fermées 72 h, mais plus d'un an après l'établissement n'était toujours pas revenu à la normale. Le **CERT Santé** a recensé **422 attaques en 2023, 764 incidents en 2025** en France. Le cadre officiel français combine deux dispositifs distincts (rappelés par l'ANS) :

• **Plan Blanc numérique** (DGOS, juin 2023) — gestion de crise, mode dégradé, cellules
• **Plan de Continuité et Reprise d'Activité (PCRA)** — programme **CaRE** Axe 4, indisponibilité de ressources critiques, RTO/RPO par activité

Une thèse de pharmacie 2025 (Charlotte Hay, CHU Amiens) traite **exactement** ton cas Chimio : PCA pour Asclépios® avec « ordinateur hors réseau + clé 4G » comme module back-up, procédures papier, criticité par étape.

2. Le local-first n'est qu'une brique — la pile complète

C'est l'erreur classique : penser "j'ai un cache offline donc ça tourne". En réalité un hôpital cyberattaqué a besoin de **4 couches** indépendantes :

| Couche | Rôle | Exemple gold standard |

|---|---|---|

| **L1 — Read-only de proximité** | Lire dossiers/prescriptions figés à T-0 de l'attaque | Epic **SRO** (Shadow Read Only), Cerner BCA |

| **L2 — Read-only dégradé** | Listes patients, ADT, planning servis depuis snapshot 12 h | Epic **BCA Web** |

| **L3 — Poste totalement isolé** | PC dédié hors réseau, sans courant réseau, sorties papier | Epic **BCA PC** + classeur BCA papier |

| **L4 — Écriture locale + resync** | Saisie clinique offline, fusion ultérieure | Local-first / CRDT, Hikma Health |

Ton "local-first" est la couche L4. Sans L1/L2/L3 il ne suffit pas, parce que le ransomware **chiffre aussi tes caches** s'ils sont sur le poste connecté au moment T-0 (Armentières : sauvegardes répliquées… donc chiffrées avec).

3. Sécurité du local-first : les pièges

Le local-first multiplie la surface d'attaque. Points durs :

• **Confidentialité au repos** : chiffrement par clé dérivée d'un secret utilisateur, pas seulement BitLocker / FileVault (sinon un poste volé = dossier patient volé). Voir Mere Medical : "zero-knowledge encryption".
• **Effacement à distance** des caches d'un poste compromis (MDM type Intune/Jamf).
• **Limite temporelle du cache** : un cache de 90 jours stocke 90 j de données sensibles → définir une TTL par profil métier (urgences = 7 j, oncologie suivi = 6 mois).
• **Authentification offline** : tokens signés avec validité courte + clé hardware (YubiKey, carte CPS). Pas de mot de passe seul.
• **Non-répudiation et audit** : chaque mutation locale signée + journal append-only resynchronisé (pour traçabilité administration).
• **Backups immuables hors-bande** : règle **3-2-1-1-0** (1 copie air-gappée, 0 erreur de restauration vérifiée). C'est la principale leçon ANSSI post-Armentières.

4. Reprise après 1 semaine — le vrai défi

Ce n'est pas la panne qui tue, c'est la **reprise**. Trois questions à répondre **avant** la crise :

1. **Quel RPO acceptable par flux ?** Chimio = 0 (pas de re-prescription approximative) ; courrier = 24 h ; codage PMSI = 7 j.

2. **Où vit la sauvegarde de "il y a 2 mois" ?** Trois copies typiquement :

• **Snapshot quotidien immuable** (S3 Object Lock, Veeam Hardened Repo, bandes LTO sorties du site)
• **Réplica asynchrone air-gapped** chez le **GHT** voisin ou un GRADeS
• **Dépôt patient minimal** sur **DMP/Mon espace santé** (récupérable côté patient)

3. **Comment réinjecter les saisies offline ?** Trois stratégies, à combiner :

• **CRDT** (Yjs, Automerge) pour les flux concurrents (planning, notes)
• **Event sourcing** signé : chaque acte = événement horodaté + hash chaîné, rejouable
• **Réconciliation manuelle assistée** : double-clé pharmacien sur les conflits prescription

Pour la **resync "1 fois par jour"** : navette physique chiffrée (SSD AES-256 + courrier interne entre étages), ou **liaison out-of-band** une fois par jour (4G dédié, opérateur différent du WAN principal).

5. À quoi penser en plus (souvent oublié)

• **Identitovigilance offline** : générer des IPP temporaires non collisionnels (UUIDv7 + préfixe service) puis les fusionner.
• **Étiquettes et codes-barres** : imprimantes Zebra autonomes avec gabarits embarqués (sinon plus de bracelet patient = erreur d'administration).
• **Référentiels figés** : Vidal, CIM-10, LOINC, table des protocoles chimio doivent vivre **localement** signés + datés.
• **Horodatage** : un serveur NTP local sur batterie (sinon signatures et logs incohérents au merge).
• **Annuaire** : un AD/LDAP de secours en lecture seule (sinon plus personne ne se connecte).
• **Téléphonie** : la **ToIP** tombe avec le réseau. Garder un **PABX analogique de secours** + DECT autonome par étage.
• **Médicaments** : les armoires automatisées (Pyxis, Omnicell) ont un mode override documenté — l'inclure au PCA.
• **Laboratoire / imagerie** : middleware local (Glims, DxLab ; PACS local) qui bufferise les résultats.
• **Exercices réels** : l'ANSSI insiste — un PCA jamais joué = papier.

6. Hardware et infrastructure de secours (sécurité non bloquante)

Si le budget hardware existe et qu'on assume un compromis sécurité/soins :

• **Datacenter de secours "tier 0" hors-AD** : cluster de 3-4 hyperviseurs autonomes, AD séparé, comptes différents, tenant cloud distinct, sans relation d'approbation avec la prod. Allumé seulement en crise. C'est ce que fait la doctrine ANSSI sous le terme **"socle de reconstruction"**.
• **Boot PXE de postes "clean"** sur image durcie chargée depuis ce socle.
• **Rack "hôpital en boîte"** mobile par bâtiment : 1 serveur + switchs + AP WiFi + UPS, prêt à être branché sur une dorsale fibre noire.
• **Réseau out-of-band** : VLAN management physiquement séparé, accessible uniquement par cellule de crise.

7. Réseau de secours : ce qui marche, ce qui ne marche pas

| Option | Portée | Débit utile | Pertinent pour |

|---|---|---|---|

| **5G privée bande 3,8-4,2 GHz** | Bâtiment entier | 100 Mb/s+ | Imagerie, vidéo, EHR — gold standard émergent (CHU Oulu) |

| **WiFi 6E maillé + DAS** | Étage / cage Faraday | 100 Mb/s | Soignants, tablettes |

| **LoRa mesh peer-to-peer (sans gateway)** | 2-15 km | ~quelques kb/s | Alertes, télémétrie, signes vitaux, statut chariots |

| **DECT IP autonome** | Bâtiment | Voix | Téléphonie soignant |

| **TETRA / radio PMR** | Site | Voix + data lente | Coordination cellule de crise |

| **Starlink / liaison satellite** | Illimité | 100 Mb/s | Lien WAN secours indépendant FAI |

| **4G/5G bondé multi-opérateurs** (Peplink, Cradlepoint) | Bâtiment | 50-200 Mb/s | Lien Internet secours |

| **Smartphones soignants** | — | — | Apps PWA local-first signées MDM, scan code-barres, photo ordonnance, capture signes |

Le **WiFi longue portée à travers murs blindés** n'existe pas vraiment : les blocs opératoires sont des cages de Faraday partielles. La solution réelle est un **DAS (Distributed Antenna System)** avec antennes à chaque local + 5G privée bas-bande (n78/n77).

Le **téléphone du soignant** est sous-exploité : une PWA local-first installée, signée par MDM, avec cache patient du jour, scan code-barres bracelet, capture photo ordonnance signée temporellement = poste de secours dans la poche. Voir Hikma Health (mobile React Native + sync Rust) pour l'archétype.

8. Est-ce que ça existe déjà ? Le "shadow infrastructure gold standard"

Oui, sous plusieurs noms :

• **Epic Business Continuity Access (BCA)** — la référence mondiale, 4 niveaux (PRD → SRO → BCA Web → BCA PC + DR portal). À retenir : tout est **read-only**, l'écriture passe par le papier qui sera scanné.
• **Cerner / Oracle Health 724Access** — équivalent Cerner.
• **MEDITECH BCA** — équivalent MEDITECH.
• **OCHIN Disaster Recovery Portal** — portail DR distant avec creds séparés.
• **Programme CaRE (France, 2023-2027)** — finance précisément le PCRA, le socle de reconstruction et les exercices.
• **Hikma Health, Mere Medical, Fasten** — open source local-first FHIR pour zones à connectivité faible.

Aucun de ces produits n'est *vraiment* local-first écriture : tous sont **read-only failover + papier**. Le local-first écriture en production hospitalière est encore un sujet de recherche (étude PLOS Digital Health 2026 sur Hikma : la sync échoue dès que plusieurs cliniciens partagent le même patient en quasi temps réel).

9. Architecture cible — 10 apps × ~40 services × 10 étages × 2 bâtiments

Pour ton dimensionnement (DPI, labo, PACS, prescription, chimio, dossier infirmier, planning, courrier, ordonnance, traçabilité), une cible cohérente :

**Topologie en 4 anneaux**

1. **Anneau bâtiment** (par bâtiment) : 2 micro-datacenters redondants, fibre noire entre les deux bâtiments, UPS + groupe électrogène. Chaque app a un nœud actif/actif inter-bâtiments.

2. **Anneau étage** : un *edge node* par étage (mini-serveur 1U + switch PoE + 5G privée) hébergeant les caches local-first des services de l'étage. Survit à la perte du datacenter bâtiment.

3. **Anneau service** : tablettes/PC clients en PWA local-first (IndexedDB chiffré, SQLite WASM + CRDT). Survit à la perte de l'edge étage pendant 24-72 h.

4. **Anneau personnel** : smartphone soignant MDM, cache patient du jour, signature CPS. Survit à tout sauf perte du téléphone.

**Données par couche**

| Donnée | Anneau minimum | Stratégie |

|---|---|---|

| Identité patient, allergies, traitements actifs | service + personnel | réplique intégrale, lecture/écriture CRDT |

| Prescription chimio en cours (J-7 à J+7) | service | event-sourced, double-validation pharmacien rejouable |

| Résultats labo des 30 j | étage | cache LRU |

| Imagerie / PACS récent (7 j) | bâtiment | cache local PACS, DICOMweb |

| Imagerie historique | datacenter + cloud | sur demande, dégradable |

| Comptes-rendus PDF | étage | object store local + CDN |

| Référentiels (Vidal, CIM-10, protocoles) | service + personnel | snapshot signé, MAJ planifiée |

| Audit / traçabilité administration | service → étage → bâtiment (push-only) | journal append-only signé |

**Modules à concevoir spécifiquement résilients**

• **Module "kit crise"** dans chaque app : bouton qui bascule en mode dégradé documenté, formulaires papier pré-remplis générés via reportlab depuis le cache local, file d'attente locale pour réinjection.
• **Bus d'événements local par étage** (NATS, Redis Streams) qui survit à la perte du backbone et rejoue à la reprise.
• **Service de réconciliation** dédié qui présente les conflits par criticité au métier (pharmacien arbitre les prescriptions, secrétaire arbitre les RDV).
• **Annuaire fédéré dégradé** : copie locale signée des comptes + droits, valable 7 j, rotation hebdo.

**Pour ton flux Chimio précisément**

Chaque étape (secrétaire planning → médecin prescription dans protocole → validation pharmacien → fiche reportlab préparateur → validation préparation → bon de livraison → administration → traçabilité) devient **un événement signé** dans un journal local au service, répliqué vers l'étage. En crise :

• Lecture protocoles depuis cache service
• Saisie prescription locale → file d'attente vers pharmacie
• Si pharmacie injoignable : escalade vers pharmacien d'astreinte sur **second canal** (DECT, LoRa alerte, ou navette physique avec QR code signé)
• Génération PDF reportlab **en local** avec clé de signature embarquée (pas d'appel serveur)
• Traçabilité administration scannée bracelet → file locale → resync

C'est exactement la structure que la thèse Hay recommande, en plus systématisé.

---

**Sources principales** : DGOS Plan Blanc Numérique 2023 ; CERT-FR rapport CERTFR-2024-CTI-010 (santé) ; ANS programme CaRE Axe 4 ; thèse Charlotte Hay 2025 (Amiens, PCA Chimio) ; Epic BCA tip sheets RWJBH/BJC/OCHIN ; retour CH Armentières (INCYBER 2025) ; étude PLOS Digital Health 2026 (Hikma Health) ; IEEE LoRa mesh off-grid PMC8272137.

J'ai suffisamment d'informations pour structurer ma réponse. Je vais rédiger une synthèse en français qui suit l'ordre des questions de l'utilisateur, en citant des sources concrètes comme le Plan Blanc Numérique, Epic BCA, les travaux de Charlotte Hay sur la chimiothérapie, ainsi que des exemples de solutions comme Hikma Health et les réseaux LoRa mesh.

Je vais organiser cela en sections claires et denses, avec quelques tableaux simples où ils ajoutent de la clarté, et terminer par l'architecture cible montrant comment 10 applications, 40 services et 2 bâtiments s'articulent ensemble. Pas de documentation excessive, juste une réponse riche mais condensée.

Hardware, futurs développements et passage à l'échelle CHU

1. Hardware à avoir — la "shadow stack" concrète

Couche stockage / sauvegarde (la priorité absolue)

| Équipement | Rôle | Pourquoi |

|---|---|---|

| **Veeam Hardened Repository** (Linux + XFS + `chattr +i`) | Sauvegarde immuable on-prem | Pas de SSH root, lateral movement bloqué — ce qui a manqué à Armentières |

| **Appliance objet S3 Object Lock Compliance Mode** (Cloudian, MinIO, Quantum, Wasabi privé) | WORM, ni admin ni root ne peut effacer | Survit à un attaquant qui aurait Domain Admin |

| **Bandes LTO-9 + robot + sortie de site** | Air-gap réel, 18 To / bande natif | Seul média physiquement déconnecté |

| **NAS répliqué chez le GHT voisin** | Réplica asynchrone hors-bande | Reconstruction même si site primaire perdu |

Règle gouvernante : **3-2-1-1-0** (3 copies, 2 médias, 1 hors-site, 1 immuable, 0 erreur de restore vérifiée).

Couche compute / "socle de reconstruction"

• **Cluster hyperviseur isolé** (Proxmox / vSphere) avec **AD séparé**, pas d'approbation avec la prod, comptes différents, MFA hardware (YubiKey FIPS).
• **CPU avec confidential computing** : AMD EPYC Genoa+ (SEV-SNP) ou Intel Xeon Sapphire Rapids+ (TDX). Surcoût ~5% perfs, gain énorme : la mémoire est chiffrée, l'admin de l'hyperviseur ne peut pas lire les VM patient.
• **GPU NVIDIA H100/H200 confidential mode** si IA clinique embarquée (radio, anapath).
• **HSM réseau FIPS 140-2 niveau 3** (Thales Luna, Fortanix DSM, YubiHSM 2 pour le low-cost) pour la garde des clés de chiffrement et la signature.
• **Boot PXE durci** depuis ce socle pour réimager rapidement les postes compromis.

Couche edge par bâtiment / étage

• **Mini-rack "hôpital en boîte"** : 2 serveurs 1U (compute redondant), switch L3 PoE+, UPS, AP WiFi 6E, modem 5G secours, batterie 4 h.
• **Edge node par étage** : NUC industriel ou Dell XR4000 + SSD NVMe chiffré + UPS, héberge le cache local-first des apps de l'étage.
• **Imprimantes Zebra autonomes** (étiquettes bracelet, étiquettes prélèvement) avec gabarits embarqués.
• **Lecteurs code-barres / RFID** branchés en USB local (pas dépendants du réseau).

Couche réseau

• **5G privée bande n77/n78** (3,8-4,2 GHz) — c'est ce que Cleveland Clinic Mentor et VA Palo Alto déploient. Couvre bâtiment entier dont sous-sols, blocs, cages de Faraday, là où le WiFi meurt.
• **WiFi 6E maillé** + DAS (Distributed Antenna System) pour pénétrer les murs blindés.
• **DECT IP autonome** par bâtiment + **PABX analogique** de secours (la ToIP tombe avec le SI).
• **Liaison WAN out-of-band** : 4G/5G bondé multi-opérateurs (Peplink, Cradlepoint) + **Starlink Business** comme troisième chemin.
• **Radios TETRA / PMR** pour cellule de crise.
• **LoRa mesh peer-to-peer** (sans gateway) pour alertes critiques basse bande passante quand tout le reste tombe.

Couche utilisateur

• **Smartphones MDM** (Intune/Jamf/Workspace ONE) avec PWA local-first signée, scan code-barres, capture photo signée.
• **Cartes CPS + lecteur** ou **YubiKey** pour authentification offline forte.
• **Tablettes durcies** par chariot de soins.
• **Postes BCA dédiés** par service (un PC totalement isolé, classeur papier à côté — modèle Epic BCA PC).

2. Ce qui est en cours de développement, à surveiller

Sync engines local-first nouvelle génération

Le retour d'expérience publié récemment (Suga, scheduling film, avril 2026) est instructif : **Automerge a explosé à 4 Go d'historique CRDT pour une donnée**. Pour des données relationnelles type DPI, on va plutôt vers les **sync engines** qui font local-first sans CRDT :

• **Zero (Rocicorp)** — SQLite client ↔ Postgres serveur, mutateur côté client rejoué côté serveur, modèle "last-write-wins + arbitrage métier"
• **PowerSync** — même philosophie, basé sur la réplication Postgres, déjà utilisé en production
• **ElectricSQL** — réplication Postgres bidirectionnelle (pas encore v1)
• **TanStack DB** + **CR-SQLite** — SQLite avec extensions CRDT plus économes que Yjs/Automerge

Pour **collaboration document riche** (compte-rendu, observation médicale rédigée à 2), garder **Yjs** qui scale mieux qu'Automerge.

Confidential computing (axe le plus chaud)

• **NVIDIA annonce que d'ici 2027 tous les GPU datacenter auront le confidential computing en standard**.
• **Fortanix + NVIDIA Confidential AI Platform** (annoncée GTC oct. 2025) : turnkey on-prem pour PHI sur H100/Blackwell.
• **AMD SEV-SNP** est mature, **Intel TDX** se généralise sur Sapphire Rapids+.
• Surveille le **Confidential Zero-Trust Framework (CZF)** publié en 2025 (arxiv 2511.11836) : pattern d'architecture qui combine ZTA + TEE pour GenAI hospitalier.
• Implication pratique pour toi : tu peux mettre une **IA locale d'aide à la prescription chimio** sur GPU sans que l'admin sys puisse lire les protocoles ni les patients.

Standards FHIR à intégrer dès maintenant

• **FHIR Bulk Data Access IG v3.0.0** (déc. 2025, STU 3) — opération `$export` NDJSON pour exports massifs entre apps. C'est ça qui te permet d'**alimenter les caches local-first** au démarrage et de faire les snapshots de reprise.
• **International Patient Summary (IPS) v2.0** (oct. 2025, STU 2) — résumé patient minimal cross-frontières basé sur ISO 27269. Cas d'usage direct : un patient transféré dans un GHT voisin pendant ta crise arrive avec son IPS lisible par n'importe quel SIH conforme.
• **SMART Health Links (SHL)** — partage de l'IPS via QR code chiffré, lisible offline.
• **Smart on FHIR + UDAP** pour l'auth fédérée inter-établissements.
• **CDS Hooks** pour brancher les modules d'aide à la décision sans coupler les apps.

Réseau et identifiants

• **5G Reduced Capability (RedCap)** et **NR-Light** dans les standards 3GPP Rel-17/18 — IoT médical sur 5G privée avec autonomie sur batterie type LoRa.
• **Matter / Thread** pour l'IoT médical résilient maillé.
• **Wallets d'identité numérique européens (EUDI Wallet, projet POTENTIAL)** — l'authentification patient et soignant pourrait basculer dessus en 2026-2027.
• **Passkeys FIDO2** pour remplacer les MDP soignants.

Programme institutionnel français à suivre

• **Programme CaRE** (Cybersécurité accélération et Résilience des Établissements), Axe 4 sécurité opérationnelle → finance le PCRA, le socle de reconstruction et les exercices jusqu'en 2027.
• **HDS v2** (hébergement de données de santé, nouvelle version) — exigences renforcées sur l'immuabilité et la PRA.
• **NIS 2** (transposée 2024) → impose des PCA testés aux établissements essentiels.
• **Espace Européen des Données de Santé (EHDS)** entré en vigueur 2025 — IPS + accès patient obligatoires.

3. Autres axes d'amélioration souvent oubliés

• **Architecture Event-Driven + journal append-only signé** par-dessus tes apps existantes : chaque acte devient un événement immuable hashé (Kafka, NATS Jetstream, Redpanda). Bénéfice triple : audit, rejouabilité après crise, découplage des apps.
• **Service mesh local-first** (Linkerd, Istio en mode ambient) avec mTLS partout — chaque app peut continuer à parler aux autres même si l'AD central tombe.
• **OpenTelemetry + SIEM dédié** (Sekoia, Wazuh, Splunk) pour détecter le mouvement latéral type Armentières (ils ont eu 2 mois entre l'accès initial et le chiffrement — détectable).
• **Détection comportementale EDR/XDR** sur tous les serveurs (CrowdStrike, SentinelOne, HarfangLab).
• **Exercices de crise réels** ≥ 1/an (l'ANSSI insiste). Sans exercice, le PCA n'existe pas.
• **Doctrine "assumed breach"** : on conçoit en partant du principe que l'attaquant est déjà à l'intérieur.
• **Dépriviligiation systématique** : zéro service tournant en SYSTEM/root, tier model AD à 3 niveaux.
• **Patch management automatisé** mais avec fenêtres tests (un patch raté peut tout casser autant qu'une attaque).
• **Cyber-assurance** négociée avec couverture PRA spécifique santé.
• **Cellule SSI mutualisée GHT** (les petits hôpitaux n'ont pas de RSSI dédié).

4. Évolutions à l'échelle d'un CHU (et passage à l'échelle)

Modèle organisationnel

| Niveau | Rôle | Exemple |

|---|---|---|

| **National** | CERT-Santé, ANS, ANSSI, programme CaRE | Threat intel, financement |

| **Régional** | GRADeS (groupements régionaux d'appui à la e-santé), réplica inter-établissements | Sauvegardes croisées |

| **GHT** | Mutualisation SSI, datacenter de recours, SIH partagé | Redondance |

| **CHU** | Datacenters jumeaux, socle de reconstruction, SOC | Cœur du dispositif |

| **Bâtiment** | Edge cluster, 5G privée, UPS + groupe | Survie 72 h |

| **Étage / service** | Edge node, cache local-first, BCA PC | Survie 24-72 h |

| **Soignant** | Smartphone MDM, carte CPS, tablette | Toujours opérationnel |

Architecture cible CHU (10 apps × ~40 services × 2 bâtiments × 10 étages)

**Plateforme unifiée par capacités, pas par app** :

1. **Bus d'événements clinique** central + miroir par bâtiment (Kafka/NATS), chaque app publie ses événements FHIR.

2. **API Gateway FHIR** (HAPI, Aidbox, Firely) qui expose un dénominateur commun, masque la diversité des apps métier.

3. **Master Patient Index (MPI)** unique avec EMPI fédéré, basé sur INS.

4. **Terminology Server** central (SNOMED CT, LOINC, CIM-10, Vidal, ATC) répliqué localement à chaque edge.

5. **Gestionnaire de consentement** centralisé (FHIR Consent).

6. **Plateforme d'imagerie unifiée** (PACS/VNA + DICOMweb), cache court par étage.

7. **Datalake clinique** (Delta Lake / Iceberg) pour analytique et IA, séparé du SI de production.

8. **Plateforme d'identité** (Keycloak ou ProSanté Connect) avec mode dégradé local.

9. **Object store unifié** S3-compatible interne (MinIO) pour PDF, images, comptes-rendus.

10. **Catalogue d'API** (Backstage, Apicurio) — sans ça, à 10 apps × 40 services tu perds la maîtrise.

Comment les apps continuent à se parler entre elles ET avec d'autres apps

C'est le point clé pour ton scénario. Trois patterns à combiner :

**Pattern 1 — FHIR R4/R5 partout**

Toute donnée patient échangée passe en ressources FHIR standardisées. Une app Chimio publie un `MedicationRequest` que le DPI consomme nativement, que le PACS ignore mais que la pharmacie traite. Aucun couplage point-à-point.

**Pattern 2 — Bus d'événements append-only**

Chaque app publie ses événements (`ChimioPrescribed`, `ChimioValidated`, `ChimioDispensed`, `ChimioAdministered`). N'importe quelle autre app peut s'abonner sans que la première soit modifiée. En crise, les événements s'accumulent localement et se rejouent à la reprise dans l'ordre.

**Pattern 3 — IPS comme contrat universel**

Tout patient a un **IPS FHIR** consultable par n'importe quelle app, n'importe quel établissement, online ou offline (via Smart Health Link / QR code). C'est ton plus petit dénominateur commun de continuité.

Comment les nouvelles apps doivent être conçues pour entrer dans ce dispositif

Tu peux imposer une **checklist d'éligibilité "résilience"** à toute nouvelle app du CHU :

1. Expose et consomme du FHIR R4 (au minimum les profils français du CI-SIS).

2. Publie ses événements métier sur le bus d'événements (schéma versionné).

3. Cache local-first activable via flag, avec TTL documenté par type de donnée.

4. Mode dégradé documenté : que peut-on faire sans le serveur central ? avec le seul cache du poste ?

5. Génération de formulaires papier (reportlab/WeasyPrint) embarquée, signés et tamponnés avec un hash rejouable.

6. Authentification locale offline avec carte CPS + cache de droits ≤ 7 jours.

7. Journal append-only signé, rejouable à la reprise.

8. Test de PCA inclus dans la recette (exercice de coupure obligatoire).

9. Génère un IPS du patient à tout moment.

10. Découplage strict du DNS et de l'AD central (continue à fonctionner si AD KO).

Avec cette grille, ton bus d'événements + ton API Gateway FHIR + ton MPI deviennent les seules dépendances communes — et ce sont précisément les composants que tu redondes le plus fort.

---

**Synthèse en une phrase** : la résilience d'un CHU ne se gagne pas en empilant du hardware, elle se gagne en **standardisant les contrats (FHIR + événements + IPS), en imposant un mode dégradé à chaque nouvelle app, et en isolant un socle de reconstruction sur du confidential computing avec sauvegarde immuable** — le hardware n'est que le support de cette discipline.

HL7 FHIR — Fast Healthcare Interoperability Resources

Le problème qu'il résout

Avant FHIR, échanger une donnée patient entre deux logiciels de santé = enfer. On avait :

• **HL7 v2** (années 80) : messages texte avec pipes `|`, illisible, "interopérable" en théorie mais chaque éditeur l'interprète à sa sauce
• **HL7 v3 / CDA** (années 2000) : XML monstrueux fondé sur le RIM, théoriquement parfait, en pratique imbuvable et peu adopté
• **DICOM** pour l'imagerie, **IHE** pour les profils, **LOINC/SNOMED** pour les terminologies — chacun dans son coin

**FHIR** (prononcé "fire"), publié par HL7 International depuis 2014, fait le pari inverse : prendre les bonnes pratiques du web (REST, JSON, OAuth2) et les appliquer à la santé. C'est la **lingua franca interopérable de la santé** aujourd'hui — Epic, Cerner, Meditech, Doctolib, le DMP français, Apple Health, Google Health, l'EHDS européen, tous parlent FHIR.

L'idée centrale : tout est une "Resource"

FHIR définit ~150 **ressources** standardisées, chacune représentant un concept clinique ou administratif atomique. Quelques exemples :

| Ressource | Représente |

|---|---|

| `Patient` | un patient |

| `Practitioner` | un soignant |

| `Organization` | un hôpital, un service |

| `Encounter` | un séjour, une consultation |

| `Observation` | un résultat (TA, glycémie, labo, score) |

| `Condition` | un diagnostic, un problème |

| `MedicationRequest` | une prescription |

| `MedicationAdministration` | une administration |

| `AllergyIntolerance` | une allergie |

| `DiagnosticReport` | un compte-rendu (labo, radio, anapath) |

| `ImagingStudy` | une étude DICOM |

| `DocumentReference` | un PDF, un courrier |

| `Appointment` | un rendez-vous |

| `Consent` | un consentement |

| `ServiceRequest` | une demande d'examen |

Chaque ressource est un **objet JSON** (ou XML, ou RDF) avec une structure stable et documentée. Exemple minimaliste :

```json

{

"resourceType": "Patient",

"id": "dupont-jean",

"identifier": [{

"system": "urn:oid:1.2.250.1.213.1.4.8",

"value": "199012345678901"

}],

"name": [{ "family": "Dupont", "given": ["Jean"] }],

"gender": "male",

"birthDate": "1980-03-15"

}

```

Comment on les manipule : REST, comme une API web normale

C'est la grande rupture. Une fois qu'un serveur expose des ressources FHIR, on les manipule avec des verbes HTTP standards :

```

GET /Patient/123 → lire un patient

GET /Patient?family=Dupont&birthdate=1980-03-15 → chercher

POST /Patient → créer

PUT /Patient/123 → mettre à jour

DELETE /Patient/123 → supprimer

GET /Patient/123/$everything → tout sur ce patient

GET /Patient/123/Observation?code=8480-6 → ses tensions systoliques

```

N'importe quel développeur web sait déjà faire ça. C'est la raison principale du succès de FHIR vs HL7 v3.

Les 4 paradigmes d'échange

FHIR n'impose pas un seul style, il en propose 4 selon ton besoin :

1. **REST API** — interactif, pour les apps cliniques (le 90 % des cas)

2. **Documents** — un Bundle figé signé (équivalent CDA), pour les courriers, comptes-rendus, IPS

3. **Messages** — équivalent HL7 v2, pour les flux événementiels asynchrones

4. **Services** — opérations métier nommées, type RPC (`$validate`, `$everything`, `$export`, `$match`)

Profils, extensions et Implementation Guides — la vraie subtilité

Le standard FHIR de base est volontairement **générique et international**. Mais un patient français a un INS, un patient américain un SSN, un patient anglais un NHS Number. D'où la mécanique :

• **Profile** = contrainte sur une ressource (ex. "un Patient français a OBLIGATOIREMENT un identifiant INS")
• **Extension** = ajout de champs non couverts par le standard
• **ValueSet / CodeSystem** = liste de codes autorisés (ex. CIM-10, LOINC, SNOMED CT, Vidal)
• **Implementation Guide (IG)** = paquet cohérent de profils + extensions + valuesets pour un cas d'usage donné

Quelques IG majeurs à connaître :

| IG | Pour quoi |

|---|---|

| **US Core** | Socle obligatoire USA |

| **CI-SIS / FR Core** | Socle français (ANS) |

| **International Patient Summary (IPS)** | Résumé patient cross-frontière, ISO 27269 |

| **mCODE** | Cancérologie (très utile pour ton cas Chimio) |

| **SDOH Clinical Care** | Déterminants sociaux de santé |

| **Bulk Data Access** | Export massif NDJSON |

| **SMART on FHIR** | App tierce s'authentifiant dans l'EHR |

| **CDS Hooks** | Aide à la décision clinique branchée |

SMART on FHIR — le "OAuth de la santé"

Brique cruciale séparée mais complémentaire : **SMART on FHIR** définit comment une app tierce s'authentifie auprès d'un serveur FHIR via OAuth 2.0 + OpenID Connect, avec des scopes spécifiques santé :

```

patient/Observation.read → lit les obs du patient en cours

user/Patient.write → écrit n'importe quel patient au nom de l'utilisateur

system/*.read → backend service, accès complet

```

C'est ce qui permet à Apple Health, à un dispositif connecté, à une app de prescription tierce, de venir se brancher sur un EHR sans intégration spécifique. Le pendant français s'appelle **Pro Santé Connect** (côté soignants) et **France Connect Santé** (côté patient).

Bundle et transactions

Un `Bundle` est un conteneur de ressources. Il sert à :

• **Search results** : la liste de patients renvoyée par une recherche
• **Document** : un compte-rendu structuré (ex. un IPS est un Bundle)
• **Transaction** : créer plusieurs ressources liées atomiquement (un Patient + un Encounter + 3 Observations en un seul POST, tout ou rien)
• **Message** : un événement métier asynchrone

```json

{

"resourceType": "Bundle",

"type": "transaction",

"entry": [

{ "resource": { "resourceType": "Patient", ... }, "request": { "method": "POST", "url": "Patient" } },

{ "resource": { "resourceType": "Observation", ... }, "request": { "method": "POST", "url": "Observation" } }

]

}

```

Versions à connaître

• **DSTU2** (2015) — historique, encore vu chez Cerner
• **STU3** (2017) — toujours actif chez certains
• **R4** (2019) — **la version dominante en production aujourd'hui**, normative pour les ressources clés
• **R4B** (2022) — petits ajouts compatibles R4
• **R5** (2023) — extensions, en montée
• **R6** — en cours

En pratique : **vise R4, prévois R5**.

Ce que ça change concrètement dans ton scénario hôpital

1. **Les apps se parlent sans connecteur custom** : ta nouvelle app Chimio publie un `MedicationRequest` que le DPI Epic ou la pharmacie Asclépios consomment en natif si tous parlent FHIR.

2. **Le local-first devient possible proprement** : tu caches des ressources FHIR dans IndexedDB / SQLite, tu les rejoues telles quelles à la reprise.

3. **L'IPS te sauve en crise** : tout patient peut être résumé en un Bundle FHIR autoporté, échangeable par QR code (Smart Health Link), lisible par n'importe quel établissement de l'UE.

4. **Bulk Data Export** te donne le snapshot de reprise : un `POST /Group/oncologie/$export` te sort tous tes patients en NDJSON pour repeupler un environnement neuf après ransomware.

5. **CDS Hooks** te permet d'ajouter une aide à la décision (alerte interaction, contrôle dose chimio) sans modifier les apps.

6. **Audit natif** : la ressource `AuditEvent` standardise la traçabilité, indispensable post-crise.

Outils et écosystème

• **HAPI FHIR** (Java) — serveur de référence open source, le plus déployé
• **Aidbox**, **Firely Server**, **Medplum** — alternatives commerciales/SaaS
• **Inferno** (ONC) — suite de tests de conformité
• **Synthea** — générateur de données patients synthétiques FHIR
• **fhir-validator-app** — validation officielle
• **Postman / Insomnia** — pour explorer une API FHIR comme n'importe quelle API REST

Limites honnêtes

• **FHIR ne résout pas la sémantique** : deux établissements peuvent envoyer des `Observation` valides mais codées différemment. Sans accord sur les terminologies (LOINC, SNOMED) c'est un dialogue de sourds bien formaté.
• **Granularité fine** : un séjour patient = des dizaines de ressources interconnectées, pas trivial à reconstituer.
• **Performances** : sur des très gros volumes, FHIR REST seul ne suffit pas, d'où Bulk Data + datalakes en aval.
• **Maturité variable** : certaines ressources sont normatives (Patient, Observation), d'autres encore en draft (les ressources financières, génomiques).

---

**Résumé en une phrase** : FHIR, c'est REST + JSON + ~150 modèles cliniques standardisés + un système d'extensions/profils par juridiction, qui a réussi là où HL7 v3 a échoué, et qui est devenu en 10 ans le **socle obligatoire de toute interopérabilité moderne en santé** — y compris pour bâtir un SI hospitalier résilient au sens où tu l'évoquais.

Stages extra-hospitaliers numérique en santé — Paris / petite couronne

Le cadre à connaître d'abord

En tant qu'**interne en pharmacie** (DES Pharmacie Hospitalière, options DSPS / PHG / RPH), tu peux faire des **stages hors PUI** dans 5 domaines agréés, dont **"Instances régionales et nationales et organismes de santé"** et **"Laboratoires de recherche"**.

Procédure (source FNSIP-BM + faculté Paris-Saclay) :

1. Tu démarches le terrain de stage **directement** (CV + LM)

2. Validation par le responsable de stage

3. Accord du **coordinateur national** (Pr Patrick Hindlet, Paris-Saclay) pour les instances nationales / industrie

4. Dossier à l'**ARS IDF** au moins **4 mois avant le début du semestre** (avant 30/06 pour novembre, avant 31/12 pour mai)

5. Catalogue officiel : **fnsipbm.fr/accueil/internat/hors-hopital**

À noter : pas mal de structures qui n'ont pas d'agrément peuvent être agréées en cours de procédure, c'est à toi de pousser. Les agréments sont valables 5 ans.

1. Hub central à connaître absolument : PariSanté Campus

**2-10 rue d'Oradour-sur-Glane, 75015 Paris**. Inauguré 2021, c'est LE pôle français du numérique en santé. Y cohabitent :

• **Agence du Numérique en Santé (ANS)** — installée sur place
• **Health Data Hub (HDH)**
• **Inria Paris** (équipes santé)
• **Inserm**
• **Université PSL**
• **Plus de 100 startups** e-santé incubées

Stratégie : viser un stage chez l'un = accès à l'écosystème complet (séminaires, hackathons, conférences inter-acteurs).

2. Agences et instances nationales

Agence du Numérique en Santé (ANS)

**Paris 15e (PariSanté Campus)** • ans.sante.fr • Recrute via ans.recruitee.com

C'est probablement **ton terrain prioritaire**. 235 collaborateurs, missions :

• Régulation (référentiels, doctrine technique du numérique en santé)
• Opérateur (DMP, Mon Espace Santé, MSSanté, Pro Santé Connect)
• **CERT Santé** (équipe de réponse aux incidents cyber)

Services / équipes pertinents pour toi :

• **Direction Interopérabilité** — FHIR, terminologies (LOINC, SNOMED, CIO-LM), CI-SIS
• **Pôle Sécurité / CERT Santé** — réponse aux cyberattaques d'établissements (cf. Armentières)
• **Direction des Référentiels** — segur numérique, ordonnance numérique
• **Équipe SI-VIC** — système victimes (ils ont une offre stage Bac+5 ouverte)
• **Équipe SI-SAMU**
• **Direction Européenne** (EHDS, IPS)

À démarcher : direction-rh@esante.gouv.fr + responsable de l'équipe ciblée.

Haute Autorité de Santé (HAS)

**5 avenue du Stade de France, 93210 Saint-Denis** • has-sante.fr/jcms/p_3107968

Service à viser : **Mission Numérique en Santé (MNS)** — contact.mns@has-sante.fr

Sujets traités directement liés à toi :

• **Certification des Logiciels d'Aide à la Dispensation (LAD) PUI** — référentiel 2022
• **Certification des Logiciels d'Aide à la Prescription (LAP)**
• Évaluation des **applications mHealth**
• **Structuration de la posologie des médicaments** (ordonnance numérique)
• Évaluation des **Dispositifs Médicaux Numériques** (DMN, prise en charge anticipée PECAN)

C'est un terrain très adapté à un interne pharma + dev web.

ANSM — Agence nationale de sécurité du médicament

**143-147 boulevard Anatole France, 93200 Saint-Denis** • ansm.sante.fr

Stages accessibles aux internes pharma (instance nationale agréée). Directions à viser pour le numérique :

• **Direction des données et de l'expertise (DIDE)** — datascience pharmacovigilance
• **Pôle pharmacovigilance** (signaux faibles, BNPV, IA sur déclarations)
• **Direction de l'inspection** (inspections SI des PUI)
• **Direction des dispositifs médicaux** (logiciels DM, MDR)

Délégation au Numérique en Santé (DNS) / Ministère

**14 avenue Duquesne, 75007 Paris** (Ministère du Travail, de la Santé et des Solidarités)

La DNS pilote la **Stratégie nationale du numérique en santé** (feuille de route 2023-2027), le **Ségur Numérique**, l'ordonnance numérique. Stages possibles mais procédure plus lourde — passer par ton ARS et la coordination DGOS.

DGOS — Direction Générale de l'Offre de Soins

Même adresse ministère. Bureau pertinent :

• **Bureau PF5 — Systèmes d'information de santé** (ex-MSIOS) → pilote la modernisation des SIH

CNAM / Assurance Maladie

**50 avenue du Professeur André Lemierre, 75020 Paris**

• **Direction de la Stratégie, des Études et des Statistiques (DSES)** — analyse SNDS
• **Mission Innovations & Données** — SNDS, cartographie des pathologies
• Pilote l'**ordonnance numérique** (e-prescription)

CNIL

**3 place de Fontenoy, 75007 Paris**

• **Service Santé** — instruit les demandes d'autorisation données de santé
• **Délégation à l'Innovation** (bac à sable IA santé)

Stages accessibles, très formateurs sur RGPD santé / Privacy by Design.

ANSSI

**51 boulevard de la Tour-Maubourg, 75007 Paris** • ssi.gouv.fr

Pas une agence santé mais traite la cyber-santé via :

• **Sous-direction opérations / CERT-FR** (rapport CERTFR-2024-CTI-010 sur le secteur santé)
• **Sous-direction expertise** (doctrines homologation, hardening)

L'accueil d'internes pharma y est plus rare, mais possible si profil tech fort + pitch clair sur la cybersécurité hospitalière. Alternative : passer par le **CERT Santé** (rattaché à l'ANS) qui collabore avec l'ANSSI.

CERT Santé

Hébergé par l'ANS (Paris 15e) • cert.sante.gouv.fr

Mission : assister les établissements de santé victimes de cyberattaques. Profil rare, recherché. Très adapté à un interne pharma qui s'intéresse à la résilience SI hospitalière. Démarcher via l'ANS.

Health Data Hub (HDH)

**PariSanté Campus, 75015** • health-data-hub.fr

Plateforme nationale données de santé. Équipes pertinentes :

• **Direction Technique** (data engineering, sécurité, FHIR)
• **Direction des Projets** (accompagnement des porteurs de projet)
• **Direction Citoyenne et Éthique**

Agence de la Biomédecine (ABM)

**1 avenue du Stade de France, 93212 Saint-Denis** • agence-biomedecine.fr — Registres greffes/AMP, données biomédicales.

Santé Publique France

**12 rue du Val d'Osne, 94415 Saint-Maurice** • santepubliquefrance.fr — Direction Data et Numérique, surveillance épidémiologique numérique.

ARS Île-de-France

**35 rue de la Gare, 75019 Paris** • iledefrance.ars.sante.fr

• **Direction de l'Offre de Soins / Pôle PUI** (ars-idf-dossier-pui@ars.sante.fr)
• **Direction de la Transformation et du Pilotage** — projets e-santé régionaux
• Lien avec **SESAN** (GRADeS d'IDF)

SESAN — GRADeS Île-de-France

**Paris 18e** • sesan.fr — opérateur e-santé régional, déploie ViaTrajectoire, le DPI partagé territorial, etc. Stages accessibles, peu connus, terrain très concret.

3. Recherche académique

Inria — Institut national recherche en sciences et technologies du numérique

• **Inria Paris** (2 rue Simone Iff, 75012)
• **Inria Saclay** (Palaiseau)
• Équipes santé : **HeKA** (santé numérique, INSERM/Inria/UPC, Hôpital Necker), **SIMBIOTX**, **EPIONE** (Sophia mais collabos Paris), **HEPHAISTOS**
• Postuler via **jobs.inria.fr** (catégorie "Stagiaire de la recherche")

Inserm

**101 rue de Tolbiac, 75013 Paris** (siège) + ~250 unités en France

• Procédure : démarcher directement le directeur de l'unité visée, 3 à 6 mois avant
• Unités à regarder : **U1138 Cordeliers** (informatique biomédicale), **U1153 CRESS** (épidémio + IA santé), **U1169 INSERM-CEA** (imagerie)
• **HeKA** (UMR S 1138, équipe de Anita Burgun) — référence française du numérique clinique

LIMICS — Laboratoire d'Informatique Médicale et d'Ingénierie des Connaissances en e-Santé

**Sorbonne Université, Hôpital Saint-Antoine, 75012** • limics.fr — pilote en France pour SNOMED/terminologies, ontologies médicales, NLP médical.

Centre Borelli, ENS Paris-Saclay

Données de santé, IA, signal, à Cachan/Gif. Plusieurs équipes médicales liées au CHU.

CRC — Centre de Recherche des Cordeliers

**15 rue de l'École de Médecine, 75006** — équipes informatique médicale, pharmaco-épidémio.

MaIAGE (INRAE Jouy-en-Josas)

NLP biomédical, normalisation entités cliniques (offre stage récente sur LLM + entités biomédicales).

4. Établissements pivots avec direction numérique forte

AP-HP — Direction des Services Numériques (DSI)

**33 boulevard de Picpus, 75012 Paris**

• **DRSI** AP-HP — la plus grosse DSI hospitalière française
• **Entrepôt de Données de Santé (EDS) AP-HP** — un des plus gros datalakes santé en Europe, équipe FHIR, IA
• Stages parfois accessibles via convention recherche

AGEPS (AP-HP)

**7 rue du Fer à Moulin, 75005 Paris** • ageps.aphp.fr/nous-recrutons — accueille des internes pharma, dont sur les **systèmes d'information pharmaceutiques** (UF EMER notamment).

Groupes hospitaliers privés

• **Ramsay Santé** (siège Paris 8e) — DSI digital santé
• **Elsan**, **Vivalto** — direction des SI

5. Industrie pharma et tech santé (stages "industrie", agréés via FNSIP-BM)

Beaucoup ont des équipes **digital health / RWE / data science** à Paris :

| Acteur | Lieu | Pertinence numérique |

|---|---|---|

| **Sanofi** | Paris/Gentilly | Digital Health, RWE |

| **Servier** | Suresnes | Innovation digitale, e-essais |

| **Pierre Fabre** | Boulogne | Beauté + médicaments digitaux |

| **Ipsen** | Boulogne | Patient support apps |

| **Doctolib** | Levallois | Plateforme rendez-vous + télémédecine |

| **Withings** | Issy | Dispositifs médicaux connectés |

| **Owkin** | Paris 13 | IA + recherche clinique fédérée |

| **Implicity** | Paris | Cardiologie numérique |

| **Dawex** | Paris | Marketplace données santé |

| **Lifen** | Paris 9 | Échange documents santé |

| **Nabla** | Paris | IA copilote consultation |

| **Synapse Medicine** | Bordeaux + Paris | LAD, expertise médicament |

| **Posos** | Paris | Aide à la prescription, recherche médicament |

→ **Posos, Synapse, Lifen, Nabla** : profils **interne pharma + dev web** très recherchés.

6. Acteurs européens / internationaux à Paris

• **Commission européenne — bureau Paris** : EHDS, MDR
• **OMS bureau France** : santé numérique mondiale (Paris 15e)
• **OCDE — Direction Santé** : 2 rue André Pascal, 75116 — analyse politiques santé numérique

7. Conseils pratiques pour toi (interne pharma + dev web)

1. **Démarche-les tôt** : 6 à 9 mois avant le semestre cible. La procédure d'agrément traîne.

2. **Valorise la double casquette** : peu d'internes savent coder. Mets en avant un projet web santé concret (FHIR, prescription, traçabilité chimio…) dans ta LM.

3. **Cible les sujets chauds 2026** : ordonnance numérique, certification LAD/LAP, ePrescription européenne, IPS, EHDS, IA dans le circuit du médicament, cyber-résilience PUI.

4. **Cumule année-recherche / M2** : un M2 type **AIRE (Université Paris Cité)**, **Médecine Interventionnelle Numérique (Paris-Saclay)**, **Informatique biomédicale (Sorbonne)** débloque des terrains supplémentaires (Inria, Inserm) et une année rémunérée.

5. **Regarde les "thèses d'exercice numérique"** : la thèse de Charlotte Hay (Amiens 2025, PCA Chimio cyberattaque) que je t'ai citée précédemment est exactement le type de sujet que tu peux porter via un stage HAS / ANS / CERT Santé.

6. **Réseau** : adhère à la **FNSIP-BM** (fédération nationale), assiste aux **Journées Innov'Pharma** (industrie), au **Rencontres du numérique en santé** (DNS), aux meetups **PariSanté Campus**.

---

**Top 5 cibles si je devais te conseiller** : ANS (CERT Santé ou Interopérabilité FHIR) → HAS Mission Numérique Santé → ANSM Direction Données → Health Data Hub → un labo Inria/Inserm via M2. Ces 5 couvrent quasi tout le spectre (cyber, normes, régulation, données, recherche) et exploitent à plein ta double compétence pharma + dev web.