RGPD et données de santé : des droits Patient qui cassent votre intégration si vous les ignorez

Implémenter les droits sous forme de flux de travail suivis

Une demande de droits nécessite une vérification d'identité, une portée enregistrée, un réviseur responsable, une exécution par système et une réponse rapprochée. Par exemple, la correction de l'adresse d'un patient doit mettre à jour le dossier faisant autorité et les copies en aval sans réécrire l'historique clinique. Conservez les mises à jour en aval ayant échoué dans une file d’attente de nouvelles tentatives et enregistrez la décision finale.

L'accès, l'effacement et la portabilité sont soumis à des conditions différentes : l'effacement comporte des exceptions, tandis que la portabilité s'applique à un traitement automatisé spécifié basé sur le consentement ou le contrat. Enregistrer la base applicable de l’article 6 et la condition de l’article 9 ; le consentement n’est pas la seule voie de traitement des données de santé. Vérifier RGPD articles 6, 9 et 15 à 20.

Pour la plate-forme de données prise en charge, voir architecture des données de santé. Cet article se concentre sur le traitement des demandes entre les systèmes.

La réglementation qui a changé à jamais les données de santé

Le RGPD a fait quelque chose de sans précédent pour l’informatique des soins de santé : il a donné aux patients des droits techniques exécutoires sur leurs données. Pas seulement le droit de consulter leur dossier médical – cela existait auparavant. Le RGPD donne aux patients le droit de faire corriger leurs données dans chaque système qui les contient. Le droit de le faire supprimer. Le droit de l’emporter avec eux dans un format lisible par machine. Le droit de restreindre la manière dont ils sont traités.

Pour un hôpital exploitant un seul DSE monolithique, ces droits sont gérables. Mais pour un environnement de soins de santé moderne composé de 15, 30 ou 50 systèmes interconnectés – chacun contenant des fragments de données du patient, reliés via un moteur d'intégration – ces droits créent de profonds défis techniques que la plupart des organisations n'ont pas entièrement résolus.

Cet article ne concerne pas la théorie du RGPD. Il s’agit du travail d’ingénierie concret requis pour rendre une architecture d’intégration de soins de santé conforme au RGPD – et de ce qui se brise lorsque vous ne le faites pas.

Article 9 : Pourquoi les données de santé bénéficient d'un traitement spécial

Le RGPD classe les données de santé comme catégorie spéciale de données personnelles en vertu de l’article 9, ce qui signifie que leur traitement est interdit par défaut. Il ne peut être traité que sous l’une des nombreuses exceptions spécifiques suivantes :

Pour les ingénieurs intégrateurs, la question cruciale est la suivante : Chaque système en cours d’intégration dispose-t-il d’une base juridique valide pour les données de santé qu’il reçoit ? Il ne s’agit pas uniquement d’une question juridique : c’est une question d’architecture. Le moteur d'intégration doit être conçu pour acheminer les données uniquement vers des systèmes dotés d'une base juridique établie, et pour supprimer ou pseudonymiser les données lorsque la base est plus étroite qu'un accès clinique complet.

Les cinq droits qui créent des exigences techniques

Droit 1 : Accès (article 15)

Ce que dit le règlement : Les patients peuvent demander une copie de toutes les données personnelles qu’une organisation détient à leur sujet, y compris les finalités du traitement et les catégories de destinataires.

Ce que cela signifie pour l’intégration :

Chaque système du paysage d'intégration qui stocke les données des patients doit être interrogeable. Lorsqu'un patient exerce son droit d'accès, l'organisation doit être en mesure de collecter des données du DSE, du LIS, du RIS, du PACS, du système de facturation, du système de planification et de tout autre système contenant ses dossiers, et de présenter une image complète.

Pour les ingénieurs intégrateurs, cela signifie construire un pipeline d'inventaire de données:

Patient Access Request
        │
        ▼
┌──────────────────┐
│  Request Handler │
│  (identifies all │
│   systems with   │
│   patient data)  │
└────────┬─────────┘
         │
    ┌────┼────┬────────┬──────────┐
    ▼    ▼    ▼        ▼          ▼
  EHR   LIS   RIS   Billing   Archive
    │    │     │       │          │
    └────┴─────┴───────┴──────────┘
         │
         ▼
┌──────────────────┐
│   Aggregation &  │
│   Formatting     │
│   (structured    │
│    export)       │
└──────────────────┘
         │
         ▼
   Patient Receives
   Complete Data Set

En pratique, je construis cela en utilisant une combinaison du MPI (pour identifier tous les identifiants de patients spécifiques au système) et de requêtes ciblées sur chaque système. Le moteur d'intégration orchestre la collecte de données et compile la réponse. Sans un MPI qui croise de manière fiable les identifiants, une réponse d'accès complète est impossible : vous ne pouvez pas interroger un système pour obtenir les données d'un patient si vous ne connaissez pas son identifiant dans ce système.

Droit 2 : Rectification (article 16)

Ce que dit le règlement : Les patients peuvent demander la correction de données personnelles inexactes.

Ce que cela signifie pour l’intégration :

Une correction du nom d’un patient n’est pas une simple mise à jour de la base de données. Dans un hôpital comportant 20 systèmes connectés, la correction doit se propager à chaque système détenant le dossier du patient. C'est exactement pour cela que les messages ADT sont conçus, en particulier ADT^A08 (Mise à jour des informations Patient).

Le rôle du moteur d'intégration :

1. La correction est effectuée dans la source de vérité (typiquement le DSE ou le MPI)
2. Le DSE génère un ADT^A08 avec les données démographiques corrigées
3. Le moteur d'intégration achemine cet ADT ^ A08 vers chaque système connecté
4. Chaque système met à jour sa copie locale du dossier patient
5. Le moteur d'intégration enregistre la confirmation (ACK) de chaque destination

Le mode de défaillance : Si un système manque l'ADT^A08 — parce qu'il était hors ligne, parce que le message a échoué, parce qu'il n'était pas abonné aux mises à jour ADT — ce système continue de contenir des données incorrectes. Le droit du patient à la rectification n'a pas été pleinement satisfait.

je construis canaux de vérification de rectification dans Mirth Connect qui suivent la propagation ADT^A08. Après avoir diffusé une correction, la chaîne vérifie que chaque système destinataire a reconnu la mise à jour. Les systèmes qui ne parviennent pas à accuser réception dans le délai prévu sont signalés pour un suivi manuel.

Droit 3 : Effacement – Droit à l’oubli (article 17)

Ce que dit le règlement : Les patients peuvent demander la suppression de leurs données personnelles lorsqu'elles ne sont plus nécessaires aux fins pour lesquelles elles ont été collectées, lorsqu'ils retirent leur consentement ou lorsque les données ont été traitées illégalement.

Ce que cela signifie pour l’intégration :

Il s’agit du droit techniquement le plus difficile à mettre en œuvre dans le domaine des soins de santé, car il entre en conflit avec d’autres exigences légales. Les lois sur la conservation des dossiers médicaux dans la plupart des pays européens exigent que les dossiers cliniques soient conservés pendant 10 à 30 ans. Le moteur d’intégration doit gérer cette tension :

• Dossiers cliniques — généralement exemptés de l'effacement en vertu de l'article 17, paragraphe 3, point c) (traitement nécessaire à la santé publique) ou des lois nationales sur la conservation des dossiers médicaux
• Données non cliniques — historique de planification, enregistrements de facturation au-delà de la période de conservation, communications marketing — ceux-ci doivent être supprimables
• Archives des messages du moteur d'intégration — Les messages HL7 stockés dans la base de données de messages de Mirth Connect contiennent des PHI et doivent être soumis à des politiques de conservation et de suppression.

La cascade d’effacement :

Lorsqu'une demande d'effacement est valide (pour les données non exemptées), le moteur d'intégration doit orchestrer la suppression sur tous les systèmes :

Erasure Request (validated)
        │
        ▼
┌──────────────────┐
│  MPI Lookup      │
│  (identify all   │
│   system IDs)    │
└────────┬─────────┘
         │
    ┌────┼────┬────────┬──────────┐
    ▼    ▼    ▼        ▼          ▼
  Sys A  Sys B  Sys C  Sys D   Message
  Delete Delete Delete Delete  Archive
    │    │      │      │       Purge
    └────┴──────┴──────┘         │
         │                       │
         ▼                       ▼
┌──────────────────┐   ┌──────────────────┐
│ Deletion         │   │ Archive Deletion │
│ Confirmation Log │   │ Confirmation Log │
└──────────────────┘   └──────────────────┘

La suppression elle-même doit être enregistrée (comme preuve de conformité) – mais le journal ne doit pas contenir les données supprimées. J'enregistre le fait que les données ont été supprimées, les systèmes sur lesquels elles ont été supprimées et les horodatages, sans enregistrer ce qui a été supprimé.

Droit 4 : Portabilité des données (article 20)

Ce que dit le règlement : Les patients peuvent recevoir leurs données personnelles dans un format structuré, couramment utilisé et lisible par machine et les transmettre à un autre responsable du traitement.

Ce que cela signifie pour l’intégration :

FHIR a été pratiquement conçu pour ce droit. Une ressource FHIR Patient, ainsi que les observations, conditions, demandes de médicaments et autres ressources cliniques associées, fournissent exactement le « format structuré, couramment utilisé et lisible par machine » qu'exige l'article 20.

Pour les demandes de portabilité, je construis des canaux d'export qui :

1. Interrogez le MPI pour tous les identifiants des patients
2. Recueillir les données cliniques de chaque système via le moteur d'intégration
3. Transformez les données en ressources FHIR R4 (ou en FHIR Bundle)
4. Conditionner le lot pour le patient ou l'organisme d'accueil

Dans le contexte européen, le Résumé international Patient (IPS) — un profil de document FHIR normalisé selon la norme CEN EN 17269 et adopté par l'EHDS — fournit un format normalisé pour la portabilité transfrontalière. J'implémente la génération IPS dans le cadre du flux de travail de portabilité, garantissant que les données exportées ne sont pas seulement lisibles par machine mais sémantiquement interopérables.

Droit 5 : Limitation du traitement (article 18)

Ce que dit le règlement : Les patients peuvent demander que leurs données ne soient pas traitées (sauf pour le stockage) pendant la résolution d'un litige concernant l'exactitude ou la licéité.

Ce que cela signifie pour l’intégration :

C’est opérationnellement complexe. Le moteur d'intégration doit être capable de geler les données d'un patient en transit — empêchez-les de circuler vers les systèmes en aval — sans les supprimer. Les données restent stockées mais ne sont incluses dans aucun flux d'intégration actif.

J'implémente ceci en utilisant un indicateur de restriction de traitement dans le MPI. Lorsqu'une restriction est appliquée :

• Le MPI marque le patient comme « en traitement restreint »
• Tous les canaux d'intégration interrogent le MPI avant d'acheminer les données des patients
• Les messages destinés aux patients restreints sont redirigés vers une file d'attente plutôt que délivrés vers des destinations
• Lorsque la restriction est levée, les messages en attente sont libérés et traités normalement

Cela nécessite que chaque canal du moteur d'intégration inclue une vérification de restriction, une étape de pré-traitement qui interroge l'état de restriction du patient avant qu'une transformation ou un routage ne se produise.

Transferts de données transfrontaliers dans le cadre du RGPD

Les données de santé traversent fréquemment les frontières : entre les États membres de l’UE, entre l’UE et la Suisse et entre l’Europe et les États-Unis. Le chapitre V du RGPD impose des règles strictes sur les transferts internationaux :

Au sein de l'EEE

Les données circulent librement entre les États membres de l’UE/EEE. Aucune garantie supplémentaire n’est requise au-delà de la conformité standard au RGPD.

L'UE vers la Suisse

La Suisse a un décision d'adéquation de la Commission européenne, ce qui signifie que les données peuvent circuler de l'UE vers la Suisse sans mécanismes de transfert supplémentaires. Le LPD suisse impose toutefois ses propres exigences, qui doivent être satisfaites de manière indépendante.

L'UE aux États-Unis

Le Cadre de confidentialité des données UE-États-Unis (adopté en juillet 2023) prévoit un mécanisme de transfert vers des organisations américaines certifiées. Pour les organismes de santé non certifiés au cadre, Clauses contractuelles types (CCS) constituent le principal mécanisme de transfert, complété par une évaluation de l’impact des transferts (TIA) documentant les risques.

Pour les ingénieurs d'intégration, les flux de données transfrontaliers doivent être documentés dans les enregistrements de traitement et le moteur d'intégration doit être configuré pour acheminer les données uniquement via des mécanismes de transfert approuvés. J'implémente des règles de routage géographique dans Mirth Connect qui garantissent que les données destinées aux systèmes non-EEE passent par le cadre de transfert légal approprié.

Évaluations d'impact sur la protection des données pour les projets d'intégration

L’article 35 du RGPD exige une analyse d’impact sur la protection des données (AIPD) pour les traitements susceptibles d’entraîner un risque élevé pour les personnes. Les projets d’intégration des soins de santé – qui impliquent le traitement à grande échelle de données de santé de catégories spéciales sur plusieurs systèmes – déclenchent presque toujours cette exigence.

Une DPIA pour un projet d’intégration doit documenter :

1. Flux de données — chaque type de message, chaque système source et destination, chaque élément de données traité
2. Base juridique — l'exception de l'article 9 qui s'applique à chaque activité de traitement
3. Nécessité et proportionnalité — pourquoi chaque système a besoin des données qu'il reçoit (minimum nécessaire / minimisation des données)
4. Risques — qu'est-ce qui pourrait mal se passer (violations de données, erreurs d'acheminement, accès non autorisé, incompatibilités d'identité)
5. Atténuations — mesures techniques et organisationnelles (cryptage, contrôles d'accès, journalisation d'audit, précision MPI)

Je contribue aux DPIA en fournissant la documentation technique des flux de données et la spécification des garanties techniques mises en œuvre dans le moteur d'intégration. Le diagramme d'architecture d'intégration – montrant chaque système, chaque type de message et chaque élément de données – constitue le fondement de la DPIA.

La gestion du consentement en pratique

Lorsque le traitement est basé sur le consentement du patient (commun pour les données de recherche, l'accès au portail patient et le partage de données entre organisations), le moteur d'intégration doit appliquer les décisions de consentement en temps réel.

Le modèle d'intégration sensible au consentement

Inbound Message (Patient Data)
        │
        ▼
┌──────────────────┐
│ 1. Parse patient │
│    identifier    │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ 2. Query consent │
│    registry      │
│    (what has the │
│    patient       │
│    consented to?)│
└────────┬─────────┘
         │
    ┌────┴────┐
    │         │
 Consent   No Consent
 exists    (or withdrawn)
    │         │
    ▼         ▼
 Route to   Block routing
 authorized to unauthorized
 destinations destinations

Le registre de consentement stocke les décisions de consentement granulaires : quelles catégories de données, quels destinataires, quelles finalités. Le moteur d'intégration interroge ce registre pour chaque message et applique les choix du patient avant le routage.

Dans le contexte suisse des EPD, ce modèle de consentement est explicite : les patients choisissent quels professionnels de santé peuvent accéder à leurs documents EPD, et l'infrastructure d'intégration doit appliquer ces politiques d'accès à chaque point de requête.

Architecture de conformité pratique

Construire un pipeline d’intégration des soins de santé conforme au RGPD ne consiste pas à ajouter une couche de conformité par-dessus. Cela nécessite de concevoir une architecture intégrant dès le départ une protection des données – ce que l’article 25 du RGPD appelle protection des données dès la conception et par défaut.

Les principes architecturaux clés :

• Données minimales à chaque saut — chaque destination reçoit uniquement les données dont elle a besoin
• Routage sensible au consentement — les décisions de consentement des patients sont appliquées au niveau de la couche d'intégration
• Piste d'audit complète — chaque décision d'accès, de transformation et de routage aux données est enregistrée
• Infrastructure de réalisation des droits — l'accès, la rectification, l'effacement, la portabilité et la restriction sont techniquement pris en charge, et pas seulement des engagements politiques
• Sensibilisation transfrontalière — les règles de transfert de données sont appliquées par une logique de routage géographique

Je construis des architectures d'intégration de soins de santé conformes au RGPD qui mettent en pratique ces principes, en utilisant les profils Mirth Connect, FHIR et IHE pour créer des pipelines où la conformité est appliquée par l'architecture, et pas seulement documentée dans les politiques. Si votre organisation a besoin d'aligner son infrastructure d'intégration sur les exigences du RGPD, je peux vous aider à concevoir et à mettre en œuvre une solution qui satisfait à la fois les régulateurs et les flux de travail cliniques.