|
9 min de lecture
|

Synchronisation d'instances Aidbox conforme à HIPAA

Résumer cet article avec :
ChatGPTPerplexityClaudeGrok

Avez-vous des bureaux ou des cliniques partout dans le monde et souhaitez-vous centraliser vos données statistiques dans un seul entrepôt? Voulez-vous également avoir la certitude absolue que votre système est conforme à HIPAA et respecte les règles des organismes de réglementation locaux (comme le RGPD)? Ou avez-vous plusieurs bureaux aux États-Unis et souhaitez-vous mettre en place un entrepôt de données médicales pour améliorer les performances à l'échelle locale? Tout cela est réalisable grâce à la synchronisation des entrepôts de données médicales. Dans cet article, je vous présente notre expérience dans la mise en œuvre d'une synchronisation de données conforme à HIPAA entre plusieurs instances Aidbox.

La synchronisation de données entre plusieurs systèmes n'est pas une nouveauté. Elle est utilisée dans les systèmes distribués à plusieurs entrepôts de données, généralement afin d'assurer l'intégration avec de multiples systèmes ou d'améliorer les performances. Dans le domaine de la santé, ce processus est également associé à la protection des renseignements médicaux personnels (PHI). Par exemple, les données personnelles des patients ne devraient pas être transmises à un entrepôt situé dans d'autres pays.

L'équipe WaveAccess, en partenariat avec Health Samurai, a développé une solution d'extension pour Aidbox destinée à un client américain possédant des cliniques dans plusieurs pays. Cette extension prend en charge la synchronisation conforme à HIPAA entre plusieurs instances Aidbox locales et une instance Aidbox mondiale. L'autre composante essentielle de ce service est le module d'anonymisation des données, qui contribue à protéger les PHI en supprimant tous les identifiants de patients avant l'envoi des données vers une autre instance Aidbox.

Voyons maintenant notre expérience concrète dans la mise en œuvre de cette solution. Nous aborderons également les défis techniques précis auxquels nous avons été confrontés et vous expliquerons exactement comment nous les avons résolus.

Cet article sera utile aux directeurs techniques, aux gestionnaires techniques, aux chefs de projet, aux chefs d'équipe et aux autres personnes techniques responsables du transfert de données entre plusieurs serveurs FHIR.

Continuez la lecture pour découvrir :

  • Description du cas d'utilisation
  • Conformité à HIPAA
  • Défis liés à la synchronisation
  • Structure et flux de travail du module de synchronisation

1. Description du cas d'utilisation

Le client exploite un réseau de cliniques dans plusieurs pays, avec un siège social aux États-Unis. Il dispose de plusieurs applications locales à l'intention des praticiens, qui utilisent des instances Aidbox comme entrepôts de données médicales, ainsi qu'une application mondiale à des fins administratives avec son propre Aidbox. L'Aidbox mondial doit contenir des informations médicales provenant du niveau local à des fins statistiques, de gestion, etc. D'autre part, les Aidboxes locaux doivent disposer d'informations cohérentes sur la structure organisationnelle et les données géopositionnelles contenues dans l'Aidbox mondial. Cela signifie que les Aidboxes locaux doivent envoyer certaines informations anonymisées sur les patients, les rendez-vous, les observations, les diagnostics et d'autres entités connexes vers l'Aidbox mondial, et recevoir en retour des informations spécifiques concernant leur emplacement (comme une liste des pays, États et organismes disponibles, etc.).

Pour mettre en œuvre le processus d'échange de données, nous devons développer un module de synchronisation capable de configurer et d'effectuer une synchronisation bidirectionnelle avec la possibilité d'anonymiser les PHI des patients.

L'architecture de haut niveau se présente comme suit :

Les Aidboxes locaux recueillent les données provenant des applications locales. Les services de synchronisation reçoivent ces données, les anonymisent et les transfèrent vers l'Aidbox mondial. Ces services gèrent également le processus d'envoi de données depuis l'Aidbox mondial vers le niveau local.

Cette approche contribue à protéger les PHI des patients. Les services de synchronisation étant hébergés localement, les informations sensibles sont également traitées localement. Une fois le processus d'anonymisation accompli par ces services, les données médicales peuvent être transférées en toute sécurité vers l'Aidbox mondial.

2. Conformité à HIPAA

La loi Health Insurance Portability and Accountability Act de 1996 (HIPAA) est une loi fédérale qui exige la création de normes nationales visant à protéger les renseignements de santé sensibles des patients contre toute divulgation sans leur consentement ou à leur insu. Ces données sensibles sur les patients sont appelées renseignements médicaux personnels (PHI) et comprennent les données démographiques ainsi que les données permettant d'identifier les personnes, notamment le nom, l'adresse, la date de naissance et le numéro d'assurance sociale.

Comment les organisations peuvent-elles transférer, recueillir et traiter les données médicales des patients? Selon la règle de confidentialité HIPAA, il n'existe aucune restriction quant à l'utilisation ou à la divulgation d'informations de santé dépersonnalisées (anonymisées). La façon la plus simple de dépersonnaliser les données consiste à supprimer tous les identifiants spécifiés et toute autre information susceptible de servir à identifier un patient.

Cela signifie qu'une solution conforme à HIPAA doit disposer d'une fonctionnalité d'anonymisation qui supprime tous les identifiants de patients des données médicales avant leur transfert vers un autre entrepôt.

Si vous souhaitez en savoir davantage sur HIPAA, vous trouverez des informations plus détaillées sur le site du U.S. Department of Health & Human Services ou en lisant notre article Aidbox HIPAA book / Part 1 / Technical safeguards.

3. Module de synchronisation Aidbox

Examinons maintenant notre solution. Selon les exigences, le service de synchronisation doit offrir les fonctionnalités suivantes :

  • Synchronisation bidirectionnelle entre les Aidboxes locaux et mondial
  • Anonymisation des données conforme à HIPAA
  • Configuration de la synchronisation

3.1 Structure générale

Dans le cas le plus courant, l'architecture du module de synchronisation ressemble au diagramme ci-dessous :

Le module reçoit les données d'un Aidbox local, les anonymise et les envoie vers l'Aidbox mondial. Au cours du processus de développement, nous avons été confrontés aux défis suivants :

  • Comment déterminer quelles données d'un Aidbox local ont été modifiées et doivent donc être envoyées vers l'Aidbox mondial?
  • Comment s'assurer que seules des instances Aidbox prédéfinies peuvent effectuer une synchronisation avec l'Aidbox mondial?
  • Comment mettre en œuvre l'anonymisation des données?

Passons en revue ces défis.

3.2 Suivi des modifications de données

La tâche de synchronisation des données ne peut être accomplie sans déterminer quelles entités ont été modifiées depuis la précédente itération de synchronisation. Aidbox fournit un mécanisme de suivi des modifications de ressources appelé Aidbox Changes API. Plutôt que d'utiliser des opérations d'exportation-importation d'entités ou des opérations en lot, le Changes API s'appuie sur un mécanisme basé sur des itérations de différentes versions, ce qui offre une transparence supplémentaire du processus. Cela s'avère très utile en cas d'incident pouvant survenir durant le processus de synchronisation.

Nous avons également créé une ressource personnalisée appelée ChangesInfo qui contient un nom d'entité et un numéro de version. Au cours du processus de synchronisation, nous récupérons cette ressource pour chacun des types de ressources FHIR en cours de synchronisation, obtenons sa version et appelons le point de terminaison $changes. Si des entités ont été modifiées depuis la précédente itération de synchronisation, le point de terminaison retourne la liste de ces entités. Enfin, nous créons une transaction Aidbox avec une opération PUT, POST ou DELETE pour chacune des entités modifiées.

3.3 Contrôle de la synchronisation

Le processus de synchronisation doit être sécurisé et contrôlable. C'est pourquoi nous avons défini une autre ressource personnalisée, AidboxInstance, qui a été ajoutée à l'Aidbox mondial. Elle permet de restreindre l'accès des Aidboxes locaux à l'Aidbox mondial pour l'exécution de la synchronisation. À chaque interaction du processus en arrière-plan, nous vérifions l'entité AidboxInstance pour l'Aidbox local afin de nous assurer qu'elle existe dans la base de données de l'Aidbox mondial et qu'elle doit être synchronisée.

3.4 Anonymisation des données

L'anonymisation des données est le processus de protection des informations privées ou sensibles par l'effacement ou le chiffrement des identifiants reliant une personne aux données stockées. Dans notre cas, les informations sensibles à anonymiser sont les attributs identifier, name, telecom et address de la ressource FHIR Patient, les attributs personnalisés patientFirstName, patientLastName et patientMiddleName dans la ressource FHIR QuestionnaireResponse, ainsi que l'attribut answer de certaines ressources FHIR QuestionnaireResponse associées à des questions telles que « Courriel personnel », « Nom », « Téléphone », « Date de naissance » et « Adresse ».

Lorsque les données transitent par le module de synchronisation, celui-ci efface ces attributs. Il va sans dire que l'ensemble des entités et attributs FHIR devant être effacés peut être configuré dans l'application.

3.5 Flux de travail de synchronisation

Le processus de synchronisation des données est illustré dans les deux diagrammes suivants. Le premier représente le processus d'envoi de données depuis les Aidboxes locaux vers l'Aidbox mondial. Le second montre le processus inverse.

La première étape du transfert de données de l'Aidbox local vers l'Aidbox mondial consiste à identifier toutes les modifications de données à l'aide de l'Aidbox Changes API. Ensuite, les données sont traitées par le module d'anonymisation pour supprimer tous les attributs PHI. Finalement, les données sont transférées vers l'Aidbox mondial. Le processus de transfert de données de l'Aidbox mondial vers l'Aidbox local est identique, à l'exception de la partie anonymisation. Les données transférées depuis le niveau mondial sont davantage de nature administrative et ne contiennent aucune information sur les patients. Ce type de données médicales n'est pas couvert par HIPAA et peut être transféré sans aucune restriction.

3.6 Résumé

En conséquence, le module de synchronisation est un service isolé qui fonctionne en arrière-plan et assure la synchronisation entre les entités Aidbox locales définies et l'entité Aidbox mondiale. Il dispose également d'une API permettant d'effectuer manuellement la synchronisation de types d'entités distincts.

Pour conclure cette section, je souhaite énumérer les avantages de cette solution :

  • Maintenance simplifiée. En s'appuyant sur le Changes API, le service fournit des informations sur chaque étape du processus de synchronisation pour chaque entité, ce qui facilite la détection de tout problème.
  • Grande personnalisation. Nous pouvons ajouter d'autres étapes intermédiaires, comme nous l'avons fait avec le processus d'anonymisation. Cela peut avoir une incidence sur les performances finales, mais nous appliquons le multithreading et le parallélisme pour réduire ces coûts supplémentaires.
  • Garantie de sécurité. Nous avons spécifié les accès pour la synchronisation pour chaque instance Aidbox locale. Cela signifie que seuls certains Aidboxes peuvent effectuer une synchronisation avec l'instance mondiale.
  • Conformité à HIPAA. L'Aidbox mondial reçoit et stocke uniquement des informations de santé dépersonnalisées. Le module d'anonymisation supprime tous les identifiants et autres informations sensibles des données, ce qui les rend sûres pour le transfert.

Pour explorer la synchronisation conforme à HIPAA dans vos systèmes, envisagez d'utiliser la version gratuite d'Aidbox. Elle offre un environnement sécurisé pour tester et développer des processus de synchronisation, en proposant tous les outils nécessaires sans aucune limitation de fonctionnalités.

4. Conclusion

Dans cet article, nous avons partagé notre expérience dans la mise en œuvre d'un module pour le processus de synchronisation Aidbox conforme à HIPAA. La synchronisation de plusieurs environnements d'entrepôts de données médicales est d'une importance capitale pour les systèmes d'information de santé distribués ou mondiaux. Un processus de synchronisation bien configuré permet aux organisations médicales de recueillir efficacement des données statistiques pouvant être utilisées à des fins de recherche médicale ou de gestion, ou d'améliorer les performances en intégrant des entrepôts dans l'architecture du système. Quel que soit l'objectif visé, il ne faut pas oublier la protection des PHI des patients et l'anonymisation des données.

Si vous avez des bureaux dans différents pays, souhaitez intégrer un entrepôt de données médicales ou avez tout simplement des questions, n'hésitez pas à nous contacter. L'équipe Health Samurai et nous-mêmes serons heureux de vous aider.

Auteur : Paul Chayka, Expert en solutions de santé | Chef de projet et chef d'équipe chez WaveAccess WaveAccess Logo

Voir aussi : Gestion des données multi-cliniques avec OrgBAC.

Partager cet article
Comments
Comments
Sign in
Loading comments...
Subscribe to our blog

Get the latest articles on FHIR, interoperability, and healthcare IT.