Points clés
- L'interopérabilité entre systèmes de santé (HL7, FHIR, IHE) est nécessaire à la continuité des soins mais multiplie les surfaces d'attaque et les points d'exposition.
- Chaque interface, API ou connecteur supplémentaire est un vecteur d'attaque potentiel qui doit être sécurisé, documenté et surveillé.
- La sécurité de l'écosystème est limitée par son maillon le plus faible — un partenaire insuffisamment sécurisé peut compromettre l'ensemble du réseau d'échange.
- La gouvernance de l'interopérabilité doit inclure un inventaire précis des interfaces, une qualification sécurité des partenaires, et une surveillance active des flux.
Les vecteurs de risque liés à l'interopérabilité
L'interopérabilité crée des vecteurs de risque spécifiques. Les APIs exposées sans authentification forte permettent des accès non autorisés. Les connecteurs HL7 v2 sur canal non chiffré exposent des messages contenant des données médicales. Les interfaces IHE non validées permettent des injections de données corrompues. Les systèmes partenaires moins bien sécurisés deviennent des points d'entrée dans l'écosystème d'échange. Chacun de ces vecteurs doit faire l'objet d'une analyse de risque spécifique avant mise en production.
FHIR R4 : standard d'échange et surface d'attaque
FHIR R4 est devenu le standard de référence pour l'échange de données de santé. Son architecture REST/JSON facilite l'intégration mais impose des exigences de sécurité précises. L'authentification doit reposer sur OAuth2/SMART on FHIR avec validation stricte des scopes. Les endpoints FHIR doivent être protégés par un API Gateway capable de filtrer les requêtes malformées, détecter les comportements anormaux (volume de requêtes inhabituel, patterns d'accès suspects), et journaliser l'ensemble des accès. Un serveur FHIR exposé sans ces protections est une base de données médicale accessible sur internet.
La qualification sécurité des partenaires d'échange
La sécurité de l'écosystème d'échange est limitée par son maillon le plus faible. Un partenaire qui accède à vos données via une interface sécurisée mais dont les propres systèmes sont insuffisamment protégés peut permettre l'exfiltration de données extraites via votre interface. La qualification sécurité des partenaires — questionnaire de sécurité, audit sur site pour les partenaires critiques, exigences contractuelles de niveau de sécurité — est un prérequis à tout échange de données de santé.
L'inventaire des interfaces : prérequis à la gouvernance
La gouvernance de l'interopérabilité commence par un inventaire exhaustif et maintenu des interfaces actives. Pour chaque interface : le système source, le système cible, le protocole d'échange, les données échangées, le responsable de l'interface côté émetteur et récepteur, et l'état de sécurité (chiffrement, authentification, tests de sécurité réalisés). Cet inventaire est rarement complet dans les organisations de santé — des interfaces légacy subsistent sans responsable identifié et sans documentation à jour. Ce sont des angles morts potentiels.
La surveillance active des flux d'échange
La surveillance des flux d'échange doit être active — pas uniquement rétrospective sur incident. Des outils de surveillance des API (APIM) et des flux HL7/FHIR permettent de détecter des anomalies en temps réel : volume de données échangé anormalement élevé, requêtes sur des ressources inhabituelles, accès hors des plages horaires normales, erreurs d'authentification répétées. Ces indicateurs, corrélés avec des règles de détection adaptées au contexte de santé, permettent d'identifier les tentatives d'accès non autorisé avant l'exfiltration de données.