Plateforme de données de santé certifiée HDS

Le groupement d'établissements de santé que nous avons accompagné réunissait sept structures (cliniques, EHPAD, centres de soins) historiquement gérées chacune avec son propre SI, ses propres serveurs et, surtout, ses propres pratiques de saisie. Récupérer un dossier patient entre établissements relevait du fax, du téléphone ou d'une clé USB transportée à la main. Au-delà de l'inefficacité — 18 minutes en moyenne pour reconstituer un parcours patient — le risque était surtout réglementaire : aucune des sept structures n'aurait passé un contrôle CNIL approfondi en l'état. La cible était une plateforme unique, certifiée HDS, capable de centraliser les données sans casser l'autonomie clinique de chaque site. Le cœur technique est une API FHIR R4 implémentée en Node.js avec Fastify, hébergée chez OVH HDS à Strasbourg. FHIR R4 n'est pas un détail cosmétique : il impose une structure ressource par ressource (Patient, Encounter, Observation, Condition, MedicationRequest…) qui contraint les développeurs à modéliser le domaine clinique correctement plutôt qu'à inventer des schémas ad-hoc. Nous avons exposé environ 40 ressources FHIR avec leurs interactions canoniques (search, read, history, $everything), et toute écriture passe par des profils de validation StructureDefinition pour rejeter les payloads malformés avant même d'atteindre la base. L'isolation multi-établissement est implémentée via PostgreSQL Row Level Security. Chaque ligne porte un `facility_id`, et une policy `USING (facility_id = current_setting('app.current_facility')::int)` s'applique en lecture comme en écriture. Le middleware Fastify positionne ce GUC en début de transaction depuis le claim JWT du praticien, et la session est invalidée si la valeur est modifiée pendant la requête. Pour les cas légitimes de partage (urgences, parcours coordonnés), une seconde policy autorise l'accès via une table `consent_sharing` qui matérialise les autorisations patient — la lecture cross-établissement reste donc auditable et révocable par l'usager. La pseudonymisation est systématique côté stockage. Le nom, le prénom, la date de naissance et l'INS-NIA sont chiffrés au niveau colonne (pgcrypto + clés dérivées par établissement gérées dans Vault), et les requêtes de recherche passent par des index sur des digests salés. Un attaquant qui exfiltrerait la base sans les clés Vault obtiendrait des dossiers cliniques anonymisés — utiles statistiquement, mais non rattachables à une personne. Les sauvegardes WAL et snapshots ne contiennent jamais de clés et sont stockés dans un compartiment HDS distinct, avec rétention 7 ans conformément au cadre santé français. L'audit trail est l'élément que les auditeurs HDS examinent en premier. Chaque lecture, écriture ou export produit un événement signé contenant `(practitioner_id, patient_id, action, resource_ref, hash_prev, hash_curr)`. Le hash courant est calculé sur l'événement plus le hash précédent — une chaîne hash-linked similaire à un mini-blockchain, mais en append-only sur PostgreSQL. Tenter de supprimer ou modifier un événement casse la chaîne et déclenche une alerte SOC immédiate. Cet audit alimente aussi le portail patient (article L1111-7 du Code de la santé publique) qui permet à chaque patient de consulter qui a accédé à son dossier. Les intégrations externes ont consommé un tiers du projet. ProSantéConnect (équivalent FranceConnect pour les professionnels de santé) impose un flux OIDC avec validation du certificat CPS au niveau hardware sur les postes médicaux — pas trivial à reproduire en environnement de recette. L'intégration DMP via Interop'Santé exige des certificats X.509 signés par l'IGC-Santé, un échange de métadonnées CDA-R2 et une gestion fine des matricules INS. Nous avons écrit un proxy local en Go qui isole ces complexités du backend principal, ce qui a divisé par trois le temps moyen d'onboarding d'un nouveau site. Après 18 mois en production, la plateforme héberge 312 000 dossiers patients, n'a connu aucun incident de sécurité (ni interne ni externe), et son certificat HDS a été renouvelé sans réserve à la première itération de l'audit annuel. Le temps moyen de récupération d'un dossier inter-établissements est passé de 18 minutes à 4 secondes. L'automatisation de la saisie administrative — INS-NIA, droits CPAM, allergies importées du DMP — a libéré l'équivalent de 6 ETP qui ont été redéployés sur le soin direct, ce qui est le seul KPI que la direction du groupement a effectivement publié.