Intégration d'un RAG médical dans un SIH hospitalier : flux HL7/FHIR, anonymisation NIR et étanchéité DMZ

Dans les établissements de santé (Centres Hospitaliers Universitaires, cliniques privées, groupements hospitaliers de territoire - GHT), l’intelligence artificielle générative suscite un intérêt massif auprès du corps médical. La promesse d’un assistant capable de synthétiser un dossier patient de 200 pages en 10 secondes ou de pré-rédiger un compte-rendu d’hospitalisation (CRH) au format SOAP répond directement au surmenage des praticiens.

Cependant, pour la Direction des Systèmes d’Information (DSI) et le Responsable de la Sécurité des Systèmes d’Information (RSSI) hospitalier, le déploiement soulève des verrous techniques et réglementaires d’une sévérité extrême :

• L’impératif de certification HDS (Hébergeur de Données de Santé) et l’application stricte de l’Article 9 du RGPD prohibent tout transfert de données médicales vers des clouds non accrédités ;
• L’hétérogénéité des protocoles hospitaliers : le Système d’Information Hospitalier (SIH) communique via des messages normalisés HL7 v2.x, HL7 FHIR (Fast Healthcare Interoperability Resources) ou des fichiers DICOM pour l’imagerie ;
• L’obligation d’étanchéité réseau : le serveur d’IA ne doit en aucun cas pouvoir initier une connexion vers l’extérieur depuis la zone démilitarisée (DMZ) hospitalière.

Ce guide détaille l’architecture d’intégration de Yevi Core v1.0 au cœur d’un SIH hospitalier, avec connecteur FHIR natif et passerelle d’anonymisation du Numéro d’Inscription au Répertoire (NIR) en mémoire vive volatile.

flowchart LR
    subgraph Zone Réseau Clinique
        DPI[Dossier Patient Informatisé / SIH] -->|Message HL7 v2 / FHIR REST| EAI[Moteur d'Intégration / EAI Mirth / Enovacom]
    end

    subgraph Enclave Sécurisée DMZ Interne
        EAI -->|Requête JSON Sécurisée TLS| RAMVault[1. Privacy Vault RAM : Masquage NIR & Identité]
        RAMVault -->|Texte Clinique Pseudonymisé| ChromaLocal[2. ChromaDB Privé Médical]
        RAMVault -->|Prompt avec Contexte Ancré| LLMLocal[3. vLLM Souverain Médical]
        LLMLocal -->|Synthèse SOAP is_grounded: true| ReIdent[4. Réconciliation Sécurisée en RAM]
    end

    ReIdent -->|CRH Validé par Médecin| DPI

    style RAMVault fill:#3b82f6,stroke:#1d4ed8,color:#fff
    style LLMLocal fill:#10b981,stroke:#047857,color:#fff
    style ChromaLocal fill:#10b981,stroke:#047857,color:#fff

---

1. Le standard FHIR : structure des ressources cliniques ingérées

Pour alimenter le moteur RAG sans déstructurer les dossiers patients, Yevi Core v1.0 intègre un parseur de ressources HL7 FHIR Release 4 (R4).

Les trois ressources pivots traitées par notre pipeline :

1. Patient : Contient l’identité, la date de naissance et l’identifiant national de santé (INS / NIR). Cette ressource est immédiatement interceptée par notre module Privacy Vault pour être remplacée par un jeton cryptographique aléatoire.
2. Condition : Diagnostics codifiés (CIM-10) et antécédents médicaux du patient.
3. DiagnosticReport & Observation : Résultats d’analyses biologiques, constantes vitales et comptes-rendus opératoires textuels.

Exemple de conversion d’un flux FHIR en texte clinique nettoyé (Python)

import json
from typing import Dict, Any

class FHIRDocumentParser:
    @staticmethod
    def extract_clinical_text(fhir_bundle: Dict[str, Any]) -> str:
        """
        Extrait la substance clinique utile d'un bundle FHIR tout en
        isolant les métadonnées sensibles avant vectorisation.
        """
        clinical_sections = []

        for entry in fhir_bundle.get("entry", []):
            resource = entry.get("resource", {})
            resource_type = resource.get("resourceType")

            if resource_type == "Condition":
                code_text = resource.get("code", {}).get("text", "Diagnostic non précisé")
                clinical_sections.append(f"[DIAGNOSTIC] : {code_text}")

            elif resource_type == "DiagnosticReport":
                conclusion = resource.get("conclusion", "")
                if conclusion:
                    clinical_sections.append(f"[RAPPORT MÉDICAL] : {conclusion}")

            elif resource_type == "Observation":
                code = resource.get("code", {}).get("text", "Examen")
                value = resource.get("valueQuantity", {}).get("value", "")
                unit = resource.get("valueQuantity", {}).get("unit", "")
                if value:
                    clinical_sections.append(f"[CONSTANTE] {code} : {value} {unit}")

        return "\n".join(clinical_sections)

---

2. Le masquage NIR et PII en mémoire vive volatile (RAM Vault)

En droit français de la santé (Article L. 1110-4 du Code de la santé publique), le Numéro d’Inscription au Répertoire (NIR / numéro de Sécurité Sociale) et les données nominatives ne doivent jamais être persistés en clair dans une base vectorielle ou dans les contextes de prompt d’un modèle d’IA.

Le mécanisme RAM Vault AES-256-GCM :

1. Détection hybride Regex + NER médical : La trame FHIR passe à travers un filtre à expressions régulières spécialisé (détection du format NIR à 15 chiffres avec clé de contrôle de Luhn) couplé à un modèle de reconnaissance d’entités nommées (Named Entity Recognition) entraîné sur l’onomastique francophone.
2. Table de correspondance éphémère : Les identités réelles (“Mme Dupont Jeanne, NIR: 2 84 05 75 123 456 78”) sont substituées par des pseudonymes normalisés (“PATIENT_REF_91B2”).
3. Chiffrement volatile en RAM : La table d’association réside exclusivement dans une zone de mémoire vive chiffrée. Aucun disque dur n’enregistre cette table.
4. Réconciliation post-inférence : Lorsque le modèle de langage local a généré sa synthèse clinique, les pseudonymes sont réattribués aux bonnes identités au moment précis de l’affichage sur le terminal du praticien hospitalier.

---

3. Déploiement réseau en zone DMZ hospitalière

L’infrastructure d’accueil de la DSI hospitalière doit isoler le serveur d’IA des réseaux externes tout en autorisant les échanges contrôlés avec l’Enterprise Application Integration (EAI) hospitalier (Mirth Connect, Enovacom ou Intersystems HealthShare) :

[ Réseau Général Hôpital / Postes Soignants ]
                    │
                    ▼ (Accès Web HTTPS / Port 443 avec Auth Certificat)
   ┌─────────────────────────────────────────────────────┐
   │         DMZ INTERNE SÉCURISÉE HOSPITALIÈRE          │
   │                                                     │
   │  [ Reverse Proxy Nginx Durci ]                      │
   │         │                                           │
   │         ▼                                           │
   │  [ Passerelle Yevi Core v1.0 (Conteneur rootless) ] │
   │         │                                           │
   │         ├─> [ RAM Vault AES-256-GCM ]               │
   │         ├─> [ ChromaDB Vectorstore Local ]          │
   │         └─> [ vLLM GPU Server (Llama 3.3 / Mistral)]│
   └─────────────────────────────────────────────────────┘
                    │
                    ▼ (RÈGLE IPTABLES STRICTE)
     [ DROP ALL TRAFFIC TO WAN / INTERNET 0.0.0.0/0 ]

Règle iptables de confinement étanche :

Le serveur d’IA ne dispose d’aucune passerelle par défaut vers l’extérieur. Tout paquet tentant de sortir vers une adresse IP publique est immédiatement détruit :

# Blocage total des flux sortants vers l'extérieur sur le serveur hospitalier
iptables -P OUTPUT DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 10.120.0.0/16 -p tcp -m multiport --dports 443,8443 -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

---

4. Garantie anti-hallucination : format SOAP et ancrage strict

En médecine d’urgence ou en hospitalisation conventionnelle, une hallucination clinique peut avoir des conséquences vitales.

Pour éliminer ce risque, Yevi Core v1.0 Health Scribe applique un protocole d’ancrage strict :

• Zéro invention de paramètres : Si le compte-rendu d’admission ne mentionne pas la prise de médicaments anticoagulants, le prompt système interdit formellement au modèle de supposer une absence ou une présence. Le modèle indique explicitement : [ANTICOAGULANTS : NON RENSEIGNÉ DANS LE DOSSIER].
• Citations vérifiables (is_grounded: true) : Chaque ligne de synthèse est indexée avec l’identifiant exact de la ressource FHIR d’origine (ex: “Tension artérielle 160/95 mmHg (Source : Observation#obs-7821, 14:32)”).
• Validation obligatoire par le praticien : L’IA ne valide et ne signe aucun document. Le praticien relit, modifie si nécessaire et clique sur “Valider et intégrer au DPI”.

---

5. Synthèse des bénéfices pour les CHU et cliniques

Enjeu Hospitalier	Solution Cloud Externe	Yevi Core v1.0 Hospital Edition
Certification HDS & RGPD	Risque juridique majeur (transfert US)	100 % hébergé au sein du CHU / HDS local
Latence d’Analyse	3 à 8 secondes (dépendant du réseau)	Moins de 800 ms sur réseau local 10 Gbps
Intégration SIH	Complexe (exposition du DPI sur Internet)	Connexion directe EAI via HL7 v2 / FHIR
Facturation	Au token récurrent (imprévisible)	Licence open-source MIT, coûts fixes maîtrisés

---

🛠️ Ressources & Accompagnement Hôpitaux

• 🎯 Demander un Cadrage Technique SIH & Démonstration HDS (30 min)
• 📄 Lire notre guide sur la rédaction de comptes-rendus au format SOAP
• 💻 Accéder au code source open source de Yevi Core v1.0 sur GitHub (Licence MIT)
• 📦 Consulter les spécifications de l’Appliance physique Yevi Box (R&D)