Réponse courte : la sécurité dans une application de santé répond à quatre questions, dans l'ordre. Qui est cette personne ? Identité : un utilisateur vérifié (patient, clinicien, système) via OpenID Connect et, pour les cliniciens, l'identité professionnelle nationale ; le niveau de vérification est plus important que la force du mot de passe. Que peut-il faire ? Autorisation : jetons OAuth 2.0 (évoluant vers 2.1) avec des portées (scopes) en syntaxe SMART on FHIR, dérivées du consentement du patient pour un objectif et une durée, appliquées au niveau des données. Qu'a-t-il fait ? Responsabilité : un journal d'accès que le patient peut lire et une piste d'AuditEvent FHIR pour l'organisation. Les données sont-elles sécurisées au repos, en transit et dans les sauvegardes ? Protection : chiffrement, gestion des clés, ségrégation, restaurations testées. Autour de cela : la base de l'ISO 27001 et 27799, NIS2 et la Règle de Sécurité HIPAA, et les menaces spécifiques aux données de santé (navigation interne, erreurs de classement, rançongiciels).
La carte
La sécurité et l'identité dans une application de santé se déclinent en sept couches : l'identité via OpenID Connect et les identifiants nationaux ou professionnels, l'autorisation via OAuth 2.0 et les portées (scopes) SMART on FHIR, le consentement comme source de chaque autorisation, la responsabilité via les journaux d'accès et les événements d'audit FHIR, la protection via le chiffrement et les sauvegardes, une base technique conforme aux normes ISO 27001, ISO 27799, NIS2 et HIPAA, et le partage initié par le patient.
| Couche | Norme ou pratique | Ce que cela vous apporte | Page |
|---|---|---|---|
| Identité | OpenID Connect ; identités nationales (eIDAS, NHS login, GesundheitsID) ; identités professionnelles (eHBA, CPS, UZI) | Un sujet vérifié avec un niveau d'assurance | SMART App Launch expliqué |
| Autorisation | OAuth 2.0 et 2.1 (PKCE obligatoire, pas de grants implicites ou par mot de passe) ; portées SMART on FHIR (patient/Observation.rs) ; services backend avec authentification client asymétrique | Jetons liés à un utilisateur, un contexte patient et une portée | SMART App Launch expliqué, SMART on FHIR backend |
| Consentement | FHIR Consent ; autorisations liées à un objectif et à une durée ; révocation ; "break-the-glass" avec justification et alerte | Le patient comme source de chaque autorisation | Plateforme de consentement patient, Demandes d'accès en clinique |
| Responsabilité | Journaux d'accès par enregistrement visibles par le patient ; FHIR AuditEvent ; stockage inviolable ; rétention | Qui a vu quoi, quand, pourquoi | Qui a consulté mon dossier médical ? |
| Protection | TLS 1.2+, chiffrement au repos avec clés gérées, chiffrement au niveau des champs pour les identifiants, environnements séparés, sauvegardes avec restauration testée | Confidentialité et disponibilité | ISO 27001 vs ISO 27799 |
| Base | ISMS ISO 27001, contrôles santé ISO 27799, mesures NIS2, Règle de Sécurité HIPAA, schémas nationaux (HDS, DSPT, C5) | Ce qu'attendent les hôpitaux, auditeurs et régulateurs | NIS2 pour les hôpitaux et les fournisseurs, HIPAA vs GDPR |
| Partage | SMART Health Links et Cards ; identifiants vérifiables | Partage initié par le patient avec un lien ou un QR code, révocable | SMART Health Links expliqué |
Identité : l'assurance avant les mots de passe
L'identité dans une application de santé repose sur un niveau d'assurance plutôt que sur la force d'un mot de passe : les niveaux d'assurance d'identité tels que NIST IAL, eIDAS substantiel et élevé, ou NHS login P9 décrivent la rigueur de la vérification d'une personne lors de son enregistrement, tandis que l'authentification multifacteur et les passkeys décrivent chaque connexion. Les professionnels de santé sont identifiés par des identités professionnelles qui sont révoquées lorsqu'ils quittent leur poste.
Une application patient qui affiche un dossier complet doit savoir qu'elle communique avec ce patient. Les niveaux d'assurance d'identité (IAL de NIST, eIDAS substantiel et élevé, NHS login P9) décrivent la force de la vérification de l'identité à l'enregistrement ; la force de l'authentification (multi-facteurs, passkeys) décrit chaque connexion. Les hôpitaux et les systèmes nationaux exigent de plus en plus des identités vérifiées issues de schémas reconnus plutôt que des inscriptions auto-déclarées, et le portefeuille d'identité numérique de l'UE deviendra un moyen accepté. Pour les cliniciens, l'identité professionnelle (et sa révocation lorsqu'une personne quitte son poste) est le système de référence pour savoir qui peut agir en tant que clinicien.
Autorisation : le consentement devient des portées (scopes)
L'autorisation dans un dossier contrôlé par le patient traduit le consentement du patient, par exemple permettre à une clinique de lire les résultats de laboratoire et les diagnostics pendant 90 jours, en portées (scopes) OAuth et en contexte patient sur le jeton, selon la syntaxe SMART on FHIR comme patient/Observation.rs. Cette autorisation est appliquée au niveau des données pour chaque requête et révoquée lorsque le patient la retire. Le mécanisme "break-the-glass" est un chemin d'accès distinct et audité.
Dans un dossier contrôlé par le patient, le consentement du patient est la politique : cette clinique peut lire mes résultats de laboratoire et mes conditions pendant 90 jours. Le système le traduit en portées OAuth et en contexte (quel patient, quelles ressources, quelles opérations) sur le jeton que le système de la clinique reçoit, les applique à chaque requête au niveau des données, et les révoque lorsque le patient retire son consentement. La syntaxe des portées de SMART on FHIR (patient/Observation.rs, patient/Condition.rs) est la langue commune pour cela ; des portées granulaires (par catégorie ou code) existent dans SMART v2 pour un contrôle plus fin. Le "break-the-glass" (accès d'urgence sans consentement) est un chemin séparé et audité avec justification obligatoire et une alerte au patient, jamais une option par défaut. Voir Plateforme de consentement patient.
Responsabilité : le journal que le patient lit
La responsabilité dans une application de santé signifie que chaque accès à un dossier, par qui, quand, quoi et sous quel consentement, est consigné dans un journal immuable que le patient peut consulter dans son application, ainsi que dans une piste d'audit organisationnelle sous forme d'événement d'audit FHIR. La norme ISO 27799 considère cela comme obligatoire, et un journal visible constitue le moyen de dissuasion le plus efficace contre la consultation non autorisée par des personnes internes.
Chaque accès à un dossier, par qui, quand, quoi, sous quel consentement, enregistré dans un journal immuable que le patient peut lire dans son application, et dans une piste d'audit organisationnelle (FHIR AuditEvent) pour les équipes de sécurité. L'ISO 27799 le considère comme obligatoire pour les informations de santé ; le principe de transparence du RGPD et les droits des patients de l'EHDS vont dans le même sens ; le plus grand moyen de dissuasion dans la vie réelle contre la navigation interne est un journal visible. Voir Qui a consulté mon dossier médical ?.
Protection : la base technique
La base technique pour la protection des données de santé repose sur le TLS partout, le chiffrement au repos avec des clés gérées et renouvelées, un chiffrement ou une tokenisation séparée pour les identifiants directs, des environnements isolés avec des données synthétiques en dehors de la production, un accès basé sur le principe du moindre privilège avec authentification multifacteur pour les administrateurs, la gestion des secrets et des vulnérabilités, des sauvegardes chiffrées testées par restauration contre les ransomwares, et une réponse aux incidents dans les délais impartis par le RGPD et la directive NIS2.
TLS partout, avec des chiffrements modernes et une épinglage de certificat dans les applications le cas échéant ; chiffrement au repos avec des clés dans un service de gestion de clés et rotation ; chiffrement séparé ou tokenisation pour les identifiants directs ; ségrégation de la production du développement, avec des données synthétiques en dehors de la production ; accès basé sur le principe du moindre privilège pour le personnel, pas de comptes partagés, authentification multi-facteurs pour tout accès administratif ; gestion des secrets ; gestion des dépendances et des vulnérabilités avec divulgation ; sauvegardes chiffrées, testées par restauration, et protégées contre les rançongiciels qui ont frappé les hôpitaux et laboratoires à plusieurs reprises (WannaCry en 2017, l'hôpital de Düsseldorf en 2020, Change Healthcare et Synnovis en 2024). Réponse aux incidents avec les délais de 72 heures du RGPD et 24 heures de NIS2 dans un seul plan d'intervention.
Menaces spécifiques aux données de santé
Les menaces spécifiques aux données de santé incluent la consultation non autorisée des dossiers de connaissances par des personnes internes, les erreurs de classement entre patients, les partages trop larges accordés pour une durée excessive, les SDK publicitaires intégrés dans les applications manipulant des données de santé, l'injection de documents dans les fonctionnalités d'IA, et la conservation sur plusieurs décennies pendant lesquelles les clés, les formats et les règles d'accès doivent survivre au personnel et aux fournisseurs.
- Navigation interne dans les dossiers de connaissances ou de personnalités publiques : accès basé sur les relations et journaux visibles.
- Erreurs de classement entre patients : réconciliation d'identité et provenance, pas seulement contrôle d'accès.
- Partage trop large : une clinique qui a obtenu "tout" pendant un an ; portées et durées avec des valeurs par défaut raisonnables.
- Applications avec SDK publicitaires : pas de traqueurs tiers dans tout ce qui traite des données de santé.
- Injection par document dans les fonctionnalités d'IA : le contenu est une donnée, jamais une instruction (RAG sur les dossiers médicaux).
- Rétention longue : les dossiers vivent pendant des décennies ; les clés, formats et règles d'accès doivent survivre au personnel et aux fournisseurs.
Chez Anpheros
Anpheros applique la carte de sécurité à elle-même avec OAuth 2.0 avec PKCE pour les applications et une authentification client asymétrique pour les backends, le consentement par objectif et durée comme source de l'accès de chaque clinique, un journal d'accès par dossier dans l'application de la personne, le chiffrement au repos et en transit, l'hébergement en UE, l'absence de SDK publicitaires, et un SMSI conforme aux normes ISO 27001 et 27799.
Anpheros applique cette carte à elle-même : OAuth 2.0 avec PKCE pour les applications et authentification client asymétrique pour les backends ; consentement par objectif et durée comme source de l'accès de chaque clinique, avec révocation et pas de "break-the-glass" silencieux ; un journal d'accès par enregistrement dans l'application de la personne ; chiffrement au repos et en transit, hébergement UE, pas de SDK publicitaires ; un ISMS conforme à l'ISO 27001 avec les contrôles santé de l'ISO 27799. Le site développeur documente l'authentification, le consentement et la sécurité.
Pages associées
- SMART App Launch expliqué
- Plateforme de consentement patient
- Qui a consulté mon dossier médical ?
- SMART Health Links expliqué
- ISO 27001 vs ISO 27799
- NIS2 pour les hôpitaux et les fournisseurs de technologies de santé
- Sécurité de la plateforme (site développeur)
- Authentification (site développeur)
Sources
- HL7 SMART App Launch
- IETF : OAuth 2.1 (projet)
- OpenID Connect Core 1.0
- HL7 FHIR R4 : AuditEvent
- HL7 FHIR R4 : Consent
- NIST SP 800-63-4 : Digital Identity Guidelines
- ISO 27799:2016
- ENISA : Lignes directrices pour l'acquisition de cybersécurité dans les hôpitaux
Questions fréquentes
OAuth 2.1 est-il différent de 2.0 ?
OAuth 2.1 consolide 2.0 avec ses meilleures pratiques de sécurité : PKCE est requis pour tous les clients, les grants implicites et par mot de passe sont supprimés, les URI de redirection doivent correspondre exactement, et les jetons de rafraîchissement pour les clients publics doivent être liés ou mis en rotation. SMART on FHIR v2 exige déjà la plupart de ces éléments.
Qu'est-ce que le "break-the-glass" ?
Accès d'urgence à un dossier sans le consentement préalable du patient, par un clinicien qui justifie sa demande. Cela doit être rare, enregistré, examiné et signalé au patient ; ce n'est jamais le chemin d'accès par défaut.
Pourquoi les patients devraient-ils voir le journal d'accès ?
Parce que c'est le moyen de dissuasion le plus efficace contre les accès inappropriés et l'expression la plus claire du contrôle : la personne voit quel établissement a consulté quoi et quand, et peut révoquer son consentement. L'ISO 27799 et l'EHDS vont dans le même sens.
Ai-je besoin d'un système d'audit séparé ?
Vous avez besoin d'une piste d'audit immuable (FHIR AuditEvent ou équivalent) que l'application ne peut pas modifier, conservée selon la politique, et d'une vue orientée patient en dérivée. Qu'il s'agisse d'un système séparé ou d'un stockage protégé au sein de la plateforme est un choix d'implémentation.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →