La loi Health Insurance Portability and Accountability Act (HIPAA) établit des normes aux États-Unis pour la protection des renseignements de santé permettant l'identification d'une personne. HIPAA s'applique aux « entités couvertes », qui comprennent : les régimes d'assurance maladie, les prestataires de soins de santé, les centres d'échange de renseignements sur la santé, ainsi que les organisations qui exercent certaines fonctions en leur nom, connues sous le nom d'« associés commerciaux ». Par exemple, un cabinet médical est une entité couverte, et le fournisseur du système de dossier médical électronique utilisé par les médecins de ce cabinet est un associé commercial. Les renseignements de santé permettant l'identification d'une personne gérés par les entités couvertes et leurs associés commerciaux sont appelés renseignements de santé protégés ou PHI. Il est important de comprendre que tous les renseignements de santé identificables ne constituent pas des PHI. Par exemple, si vous développez un logiciel qui reçoit des renseignements de santé directement des patients, votre organisation et votre logiciel ne sont pas réglementés par HIPAA si aucune entité couverte n'est impliquée. La règle de sécurité HIPAA exige des entités couvertes et de leurs associés commerciaux qu'ils protègent la confidentialité, l'intégrité et la disponibilité des PHI au moyen de mesures de protection administratives, physiques et techniques. Le serveur FHIR Aidbox et son infrastructure automatisée comprennent de nombreux composants intégrés qui répondent aux mesures de protection HIPAA techniques et administratives. Voyons comment les systèmes de santé propulsés par Aidbox maintiennent leur conformité à HIPAA. Révélation : HIPAA est simple lorsque vous utilisez Aidbox.
Mesures de protection techniques HIPAA
NORME § 164.312(a)(1) Contrôle d'accès
La norme de contrôle d'accès exige que vous mettiez en œuvre des politiques et des procédures techniques pour vos solutions qui maintiennent les ePHI afin de n'autoriser l'accès qu'aux personnes ou aux logiciels auxquels des droits d'accès ont été accordés. Quatre spécifications de mise en œuvre sont associées à la norme de contrôle d'accès. 1. Identification unique de l'utilisateur (Obligatoire) 2. Procédure d'accès d'urgence (Obligatoire) 3. Déconnexion automatique (Applicable) 4. Chiffrement et déchiffrement (Applicable)
- IDENTIFICATION UNIQUE DE L'UTILISATEUR (O) - § 164.312(a)(2)(i) - obligatoire
Attribuer un nom et/ou un numéro unique pour identifier et suivre l'identité de l'utilisateur.
Cette spécification exige que les solutions de TI en santé attribuent un identifiant unique à chaque utilisateur du système. Toutes les activités de l'utilisateur, notamment les sessions, les appels d'API, etc., doivent être associées à cet identifiant. Ce modèle de mise en œuvre vous offre transparence et traçabilité, et vous permet de suivre l'activité d'un utilisateur précis et de tenir les utilisateurs responsables des fonctions exercées sur les systèmes d'information contenant des ePHI. HIPAA ne définit pas d'exigences techniques concernant les formats d'identification des utilisateurs, de sorte que les approches des développeurs peuvent différer. Le module de gestion des utilisateurs et de contrôle d'accès d'Aidbox utilise des UUID pour l'identification des utilisateurs. Chaque utilisateur reçoit un identifiant unique lors du processus d'inscription. L'utilisation de cet identifiant permet de gérer les autorisations de manière granulaire. Ces fonctionnalités sont disponibles dans Aidbox avec les ressources User, AccessPolicy et Role.
Pour les organisations établies disposant d'infrastructures TI complexes, Aidbox permet l'utilisation de mécanismes d'identité fédérée pour gérer et associer des identités d'utilisateurs approuvées dans plusieurs systèmes TI, voire dans plusieurs organisations. Dans ce scénario, un UUID unique est tout de même attribué par Aidbox pour identifier un utilisateur.
- PROCÉDURE D'ACCÈS D'URGENCE (O) - § 164.312(a)(2)(ii) - obligatoire
Établir (et mettre en œuvre au besoin) des procédures pour obtenir les renseignements de santé protégés sous forme électronique nécessaires en cas d'urgence.
Cette spécification de mise en œuvre oblige à établir (et à mettre en œuvre au besoin) des procédures pour obtenir les ePHI nécessaires en cas d'urgence. Lorsqu'un incident compromettant la disponibilité du système survient, vous devez disposer d'instructions documentées et de pratiques opérationnelles qui permettront d'accéder aux ePHI nécessaires. Cela comprend non seulement des mesures de protection techniques, mais aussi un processus administratif qui accorde aux utilisateurs les privilèges nécessaires pour accéder aux ePHI dans des conditions d'urgence si une intervention manuelle est inévitable. La procédure d'accès d'urgence d'Aidbox s'appuie sur les mécanismes de sauvegarde et de réplication de l'infrastructure de base de données automatisée d'Aidbox, qui assurent l'intégrité des données. Ces mesures minimisent la possibilité de perte de données en cas d'urgence et permettent de restaurer la version la plus récente et non corrompue des ePHI.
Par exemple, l'infrastructure d'Aidbox utilise une architecture de base de données active-passive dans laquelle un nœud passif réplique en temps réel toutes les modifications effectuées sur le nœud actif. Avec la bonne configuration, le délai est réduit à quelques minutes, ce qui diminue le risque de perte de données en cas d'urgence. Cette approche garantit également une haute disponibilité, car le nœud passif est promu au rang de nœud actif si le nœud actif devient indisponible. Le module de contrôle d'accès d'Aidbox prend en charge la création de politiques d'accès d'urgence qui permettront aux utilisateurs identifiés d'accéder aux ePHI nécessaires. Les administrateurs peuvent identifier les utilisateurs qui ont besoin d'un accès d'urgence et configurer des politiques d'accès d'urgence pour récupérer les ePHI nécessaires à partir d'un environnement restauré en cas d'urgence.
- DÉCONNEXION AUTOMATIQUE (A) - § 164.312(a)(2)(iii) - applicable
Mettre en œuvre des procédures électroniques qui terminent une session électronique après une période d'inactivité prédéterminée.
Cette spécification constitue une mesure de protection raisonnable, mais elle n'est pas obligatoire et son absence ne compromettra pas votre conformité à HIPAA si vous décidez de ne pas la mettre en œuvre pour quelque raison que ce soit. Tout utilisateur qui se connecte au système devrait bénéficier d'un délai d'expiration de session par défaut. La durée de la session peut être déterminée en fonction du rôle de l'utilisateur, de la sensibilité de l'information, etc. Si un utilisateur est inactif pendant cette période, il doit s'authentifier de nouveau avant de continuer à utiliser les services.
Le module de contrôle d'accès d'Aidbox vous permet de définir un délai d'expiration pour le jeton de session JWT d'un utilisateur. Un délai d'expiration peut également être configuré pour les clients API. Plusieurs ressources client peuvent être configurées pour les rôles d'utilisateurs qui nécessitent des durées de session différentes.
- CHIFFREMENT ET DÉCHIFFREMENT (A) - § 164.312(a)(2)(iv) - applicable
Mettre en œuvre un mécanisme pour chiffrer et déchiffrer les renseignements de santé protégés sous forme électronique.
Les données ePHI doivent être chiffrées pour réduire la possibilité d'accès non autorisé. Cela peut s'appliquer non seulement au stockage de la base de données, mais aussi aux sauvegardes et aux journaux d'activité pour prévenir les accès non autorisés et l'exposition des ePHI. L'infrastructure automatisée d'Aidbox utilise par défaut des partitions chiffrées pour les données au repos. Les données sont chiffrées/déchiffrées automatiquement lors des opérations d'entrée/sortie de la base de données à l'aide des clés émises par le fournisseur infonuagique. Les clés de chiffrement sont alternées par le fournisseur infonuagique, et la période de rotation est également configurable. L'IAM du fournisseur infonuagique (AWS, Azure et Google) est utilisé pour prévenir les accès non autorisés à l'infrastructure infonuagique sous-jacente.
NORME § 164.312(b) Contrôles d'audit
Mettre en œuvre des mécanismes matériels, logiciels et/ou procéduraux qui enregistrent et examinent l'activité dans les systèmes d'information qui contiennent ou utilisent des renseignements de santé protégés sous forme électronique.
Le contrôle d'audit exige qu'un système dispose de capacités d'audit pour tenir les utilisateurs responsables des opérations effectuées à l'aide des ePHI. Un journal d'audit doit être capturé pour tous les composants logiciels utilisés dans les services conformes à HIPAA. Les meilleures directives actuelles concernant les journaux d'audit des applications de santé se trouvent dans la norme ASTM E2147-18, « Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems », qui a été choisie par ONC pour la technologie de dossier médical électronique certifiée.
Aidbox enregistre automatiquement tous les événements d'authentification, d'API, de base de données et de réseau. Les enregistrements du journal comprennent l'horodatage de l'événement, le type d'action, l'identifiant de l'utilisateur, le corps de la requête, la requête de base de données, l'identifiant du client API, etc., selon le type de journal. Par défaut, Aidbox utilise ElasticSearch pour la persistance des journaux, et Kibana/Grafana pour l'analyse et la visualisation des journaux. Vous pouvez également configurer l'intégration avec des solutions tierces de surveillance et de gestion des journaux comme Datadog, Splunk ou SumoLogic.
De plus, la surveillance et la journalisation peuvent également être configurées du côté du fournisseur infonuagique avec des solutions comme Stackdriver, CloudWatch, etc. Avec cette approche, vous pouvez examiner l'activité des clients dans les composants logiciels qui entourent le serveur principal Aidbox et la base de données. Ces composants comprennent les routeurs réseau, les serveurs mandataires Nginx, les moteurs d'orchestration de conteneurs et les environnements d'exécution d'applications.
Vous pouvez trouver plus de détails sur la journalisation et l'audit dans notre documentation.
NORME § 164.312(c)(1) Intégrité
Mettre en œuvre des politiques et des procédures pour protéger les renseignements de santé protégés sous forme électronique contre toute altération ou destruction inappropriée.
La norme d'intégrité exige que les logiciels mettent en œuvre des politiques et des procédures pour protéger les ePHI contre toute altération ou destruction inappropriée.
L'infrastructure d'Aidbox dispose de plusieurs moyens pour assurer l'intégrité des données. Tout d'abord, la plupart des opérations API sont encapsulées dans des transactions PostgreSQL avec un niveau d'isolation d'au moins « read committed ». Cela prévient les modifications concurrentes indésirables et permet une restauration en cas d'erreur lors de l'exécution d'une requête. De plus, Aidbox assure l'intégrité des données grâce à l'utilisation des mécanismes standard de réplication et de sauvegarde de la base de données PostgreSQL. Le système de sauvegarde est configuré pour exécuter des sauvegardes selon un calendrier défini (toutes les heures, quotidiennement, la nuit) et archiver les enregistrements WAL en continu. En cas de corruption des données, par exemple si une requête malveillante a été exécutée, cette approche vous permet d'effectuer une récupération à un moment précis, c'est-à-dire de restaurer la version la plus récente et non corrompue des données. Pour pouvoir effectuer une restauration à partir de la sauvegarde le plus rapidement possible, il est recommandé de tester le processus de récupération de façon proactive. Les sauvegardes sont stockées dans un stockage infonuagique hautement disponible et chiffré. Une configuration supplémentaire du stockage chez le fournisseur infonuagique, mettant en œuvre une redondance multirégionale, est possible. La réplication de la base de données et les sauvegardes peuvent être configurées par l'équipe Aidbox lors du déploiement du projet.
- MÉCANISME D'AUTHENTIFICATION DES RENSEIGNEMENTS DE SANTÉ PROTÉGÉS SOUS FORME ÉLECTRONIQUE (A) - § 164.312(c)(2) - applicable
Mettre en œuvre des mécanismes électroniques pour corroborer que les renseignements de santé protégés sous forme électronique n'ont pas été altérés ou détruits de manière non autorisée.
Aidbox n'autorise que les utilisateurs ou les services autorisés à utiliser ses API, ce qui garantit l'absence de destruction ou d'altération inappropriée ou accidentelle des ePHI. Le module de journalisation et d'audit permet d'examiner toutes les activités des utilisateurs afin que toute opération indésirable puisse être détectée et annulée.
NORME § 164.312(d) Authentification de la personne ou de l'entité
Mettre en œuvre des procédures pour vérifier qu'une personne ou une entité cherchant à accéder aux renseignements de santé protégés sous forme électronique est bien celle qu'elle prétend être.
L'authentification confirme que la personne qui tente d'accéder aux ePHI est bien celle qu'elle prétend être. Cela s'accomplit en fournissant une preuve d'identité. Il existe plusieurs façons de fournir une preuve d'identité pour l'authentification, notamment les mots de passe, les clés privées, la possession d'un appareil, ou même la biométrie.
Le contrôle d'accès d'Aidbox offre une expérience d'authentification sécurisée avec connexion par mot de passe et des flux intégrés de réception et de confirmation de mot de passe.
Pour une sécurité renforcée, Aidbox propose l'authentification multifacteur (AMF) pour protéger les comptes d'utilisateurs contre les accès non autorisés. Vous pouvez activer la 2FA pour un utilisateur et la configurer avec AuthConfig, Client et AidboxConfig. Un TOTP (mot de passe à usage unique basé sur le temps) est utilisé pour obtenir un jeton d'accès pour votre application.
À des fins de développement, des méthodes d'authentification simples comme l'authentification de base sont également prises en charge.
NORME § 164.312(e)(1) Sécurité de la transmission
Mettre en œuvre des mesures de sécurité techniques pour se prémunir contre les accès non autorisés aux renseignements de santé protégés sous forme électronique qui sont transmis sur un réseau de communications électroniques.
- CONTRÔLES D'INTÉGRITÉ (A) - § 164.312(e)(2)(i) - applicable
Mettre en œuvre des mesures de sécurité pour garantir que les renseignements de santé protégés sous forme électronique transmis par voie électronique ne sont pas modifiés de façon inappropriée sans détection jusqu'à leur élimination.
Aidbox utilise HTTP sur TLS pour la transmission des ePHI, et ce protocole garantit par conception que les données envoyées sont identiques aux données reçues. Aucun effort supplémentaire n'est requis pour se conformer à cette spécification si votre application utilise Aidbox pour tous ses besoins de transmission de données.
- CHIFFREMENT (A) - § 164.312(e)(2)(ii) - applicable
Mettre en œuvre un mécanisme pour chiffrer les renseignements de santé protégés sous forme électronique chaque fois que cela est jugé approprié.
Aidbox utilise HTTP sur TLS pour la transmission des ePHI, et ce protocole chiffre toutes les données transmises. L'infrastructure automatisée d'Aidbox est dotée d'un gestionnaire de certificats SSL qui émet et met à jour les certificats SSL automatiquement afin que vous ne manquiez pas leur expiration. En général, nous utilisons des certificats fournis par Let's Encrypt, mais tout fournisseur compatible ACME peut être configuré. De plus, l'utilisation d'un certificat existant émis par le fournisseur infonuagique (le ACM d'Amazon, par exemple) est également possible.
Dans les prochains chapitres, nous expliquerons comment Aidbox aide à couvrir les mesures de protection administratives de HIPAA.
Commencez avec le serveur FHIR Aidbox pour le stockage de données, les intégrations, l'analytique en santé et bien plus encore, ou faites appel à notre équipe pour répondre à vos besoins en développement de logiciels.
Voir aussi : Préparer FHIR pour la production.
