Chaque dossier médical volé coûte jusqu’à 20 dollars – vingt fois plus que les données de carte de crédit. Pour éviter le vol d’identité, la fraude et le chantage, toutes les applications de santé aux États-Unis doivent se conformer à la loi sur la portabilité et la responsabilité de l’assurance maladie (HIPAA). Voici notre guide simple des logiciels conformes à la loi HIPAA.
Entre autres choses, la loi HIPAA protège les informations de santé des patients.
Anthem, la plus grande compagnie d’assurance américaine, l’a appris à ses dépens.
Ce qui a commencé par un simple courriel de phishing, a conduit à la plus grande violation de données de santé de l’histoire. Les pirates ont volé les données de 79 millions de patients. Les informations comprenaient leurs noms, leurs numéros de sécurité sociale et leurs identifiants médicaux.
Les patients enragés ont poursuivi Anthem et ont obtenu un règlement de 115 millions de dollars. Bien que la société ait évité les amendes du régulateur, elle devrait dépenser jusqu’à 260 millions de dollars pour améliorer sa sécurité.
Le bureau des droits civils du HHS (OCR) supervise la conformité HIPAA. Rien qu’en 2017, il a infligé des amendes de près de 20 millions de dollars aux prestataires de soins de santé américains.
Même si vous êtes une petite organisation, négliger les exigences de l’HIPAA peut entraîner de graves problèmes.
En 2013, Fresenius Medical Care North America a connu cinq violations de données. Combinées, elles ont exposé les données de seulement 525 patients. Mais l’entreprise a dû payer une amende monstrueuse de 3,5 millions de dollars parce qu’elle n’a pas analysé correctement les risques de sécurité.
Selon le degré de négligence, il existe quatre pneus d’amendes HIPAA :
Glossaire HIPAA
Vous devez comprendre ces trois termes clés avant de vous attaquer aux exigences HIPAA.
- Informations de santé protégées (PHI) – toute donnée qui peut être utilisée pour identifier un patient.
Les PHI se composent de deux parties : les informations de santé et les identifiants personnels. Ces derniers comprennent les noms, adresses, dates de naissance, numéros de sécurité sociale, dossiers médicaux, photos, etc. des patients. Le fait qu’une personne ait reçu des services médicaux est un PHI en soi.
Qu’est-ce qui est considéré comme PHI ? La liste complète.
- Entités couvertes – organisations et individus offrant des services/opérations de soins de santé, ou acceptant des paiements pour ceux-ci.
Ils comprennent tous les fournisseurs de soins de santé (par exemple, les hôpitaux, les médecins, les dentistes, les psychologues), les plans de santé (par exemple, les fournisseurs d’assurance, les HMO, les programmes gouvernementaux comme Medicare et Medicaid) et les chambres de compensation (les organisations qui agissent comme intermédiaires entre les fournisseurs de soins de santé et les compagnies d’assurance).
- Associés commerciaux – les tiers qui traitent les RPS pour le compte des entités couvertes.
Cette catégorie comprend les développeurs d’applications de soins de santé, les fournisseurs d’hébergement/de stockage de données, les services de messagerie, etc.
Selon l’HIPAA, vous devez signer un accord d’associé commercial (BAA) avec chaque partie qui a accès à vos RPS. Décider de ne pas signer un BAA ne vous libère pas des exigences de l’HIPAA.
Les entités couvertes et les associés commerciaux doivent tous deux se conformer à l’HIPAA. La loi n’a pas de clause de « sphère de sécurité », ce qui signifie que vous devez être conforme même si vous traitez des PHI de manière non intentionnelle.
Il peut y avoir de nombreuses façons non intentionnelles par lesquelles les données sensibles peuvent entrer dans votre système.
Prenez, par exemple, un service qui permet aux médecins de diagnostiquer les conditions de la peau en fonction de photos anonymes. L’application ne manipule pas de PHI car vous ne pouvez pas identifier ses utilisateurs. Mais dès que vous ajoutez le nom ou l’adresse de la personne aux photos, elles deviennent des PHI.
Si votre application collecte, stocke ou transmet des PHI aux entités couvertes, vous devez vous conformer à l’HIPAA.
Comment devenir conforme à l’HIPAA?
Pour être conforme à l’HIPAA, vous devrez procéder à des évaluations techniques et non techniques régulières de vos efforts pour protéger les informations de santé et les documenter de manière approfondie. Le régulateur a publié un exemple de protocole d’audit qui peut vous aider à évaluer votre conformité HIPAA.
Vous pouvez engager un auditeur indépendant pour faire l’évaluation pour vous. Il existe de nombreuses organisations telles que HITRUST qui se spécialisent dans ce genre de choses. Rappelez-vous simplement que l’OCR ne reconnaît pas les certificats de tiers.
Lorsque vous développez un logiciel conforme à la loi HIPAA, vous devrez surtout vous occuper des mesures de protection techniques et physiques décrites dans la règle de sécurité.
Mesures de protection techniques. Les mesures de sécurité comme la connexion, le cryptage, l’accès d’urgence, les journaux d’activité, etc. La loi ne précise pas quelles technologies vous devez utiliser pour protéger les RPS.
Les garanties physiques visent à sécuriser les installations et les appareils qui stockent les RPS (serveurs, centres de données, PC, ordinateurs portables, etc.).
Avec les solutions modernes basées sur le cloud, cette règle s’applique surtout à l’hébergement conforme à la HIPAA.
Les garanties décrites dans la règle de sécurité peuvent être soit « obligatoires », soit « adressables ». Les deux sont obligatoires. Si vous sautez une sauvegarde « adressable », vous devez prouver qu’il s’agit d’une décision suffisamment raisonnable pour votre situation.
La loi s’applique à un large éventail de logiciels médicaux. Un système de gestion hospitalière (SGH) diffère radicalement des apps de diagnostic à distance. Mais certaines fonctionnalités sont essentielles à toutes les apps conformes à la loi HIPAA.
Voici donc une liste minimale de fonctionnalités requises pour les logiciels conformes à la loi HIPAA :
1. Contrôle d’accès
Tout système qui stocke des PHI doit limiter les personnes qui peuvent voir ou modifier les données sensibles. Selon la règle de confidentialité de l’HIPAA, personne ne devrait voir plus d’informations sur les patients que nécessaire pour faire son travail. La règle spécifie également la dé-identification, les droits des patients à voir leurs propres données et leur capacité à donner ou à restreindre l’accès à leurs PHI.
Une façon d’y parvenir est d’attribuer à chaque utilisateur un identifiant unique. Cela vous permettrait d’identifier et de suivre l’activité des personnes qui accèdent à votre système.
Puis, vous devrez donner à chaque utilisateur une liste de privilèges qui lui permettent de voir ou de modifier certaines informations. Vous pouvez réglementer l’accès à des entités individuelles de la base de données et à des URL.
Dans sa forme la plus simple, le contrôle d’accès basé sur l’utilisateur consiste en deux tables de base de données. Une table contient la liste de tous les privilèges et leurs identifiants. La seconde table attribue ces privilèges aux utilisateurs individuels.
Dans cet exemple, le médecin (ID utilisateur 1) peut créer, visualiser et modifier les dossiers médicaux, tandis que le radiologue (ID utilisateur 2) peut uniquement les mettre à jour.
Un contrôle d’accès basé sur les rôles est une autre façon de mettre en œuvre cette exigence. Grâce à lui, vous pouvez attribuer des privilèges à différents groupes d’utilisateurs en fonction de leur poste (par exemple, médecins, techniciens de laboratoire, administrateurs).
2. Authentification de la personne ou de l’entité
Après avoir attribué des privilèges, votre système doit pouvoir vérifier que la personne qui tente d’accéder aux RPS est bien celle qu’elle prétend être. La loi propose plusieurs moyens généraux pour mettre en œuvre cette protection :
Un mot de passe est l’une des méthodes d’authentification les plus simples. Malheureusement, c’est aussi l’une des plus faciles à craquer. Selon Verizon, 63% des violations de données se produisent en raison de mots de passe faibles ou volés. Un autre rapport indique qu’un cinquième des utilisateurs en entreprise ont des mots de passe facilement compromettables.
En revanche, un mot de passe vraiment sûr :
- Comprend au moins 8 à 12 caractères qui incluent des majuscules, des chiffres et des caractères spéciaux ;
- Exclut les combinaisons couramment utilisées (ex. « password », « 123456 », « qwerty » et, pour une raison inexplicable, « monkey ») et les mots de vocabulaire;
- Dispose de toutes les variations du nom d’utilisateur;
- Prévient la réutilisation du mot de passe.
Alternativement, il pourrait s’agir d’une chaîne de mots aléatoires écrasés ensemble comme un popsicle en béton.
Votre application pourrait vérifier ces exigences sur l’écran d’inscription et refuser l’accès aux utilisateurs avec des mots de passe faibles.
Il n’y a pas de chose telle que trop de sécurité. Source : mailbox.org
Certaines organisations obligent leurs employés à changer de mot de passe tous les 90 jours environ. Faire cela trop souvent peut en fait nuire à vos efforts de sécurité. Lorsqu’on les oblige à changer de mot de passe, les gens trouvent souvent des combinaisons peu originales (par exemple, mot de passe ⇒ pa$$mot).
De plus, les pirates peuvent craquer un mauvais mot de passe en quelques secondes et l’utiliser immédiatement.
C’est pourquoi vous devriez envisager d’utiliser une authentification à deux facteurs. Ces systèmes combinent un mot de passe sécurisé avec une deuxième méthode de vérification. Cela peut aller d’un scanner biométrique à un code de sécurité à usage unique reçu par SMS.
L’idée est simple : même si les pirates obtenaient d’une manière ou d’une autre votre mot de passe, ils devraient voler votre appareil ou vos empreintes digitales pour accéder aux RPS.
Mais l’authentification sécurisée ne suffit pas. Certains attaquants pourraient s’introduire entre l’appareil de l’utilisateur et vos serveurs. De cette façon, les pirates pourraient accéder aux RPS sans compromettre le compte. C’est ce qu’on appelle le détournement de session, une sorte d’attaque de type man-in-the-middle.
Un des moyens possibles de détourner une session. Source : Heimdal Security
Une signature numérique est un moyen de se défendre contre de telles attaques. Saisir à nouveau le mot de passe lors de la signature d’un document prouverait l’identité de l’utilisateur.
Lorsque les rôles dans votre système deviennent plus complexes, l’autorisation HIPAA peut entraver l’aide aux patients. Il est judicieux de mettre en place un accès d’urgence. De telles procédures permettent aux utilisateurs autorisés de consulter toutes les données dont ils ont besoin lorsque la situation l’exige.
Un médecin pourrait, par exemple, accéder aux PHI de tout patient en cas d’urgence. Dans le même temps, le système notifierait automatiquement plusieurs autres personnes et lancerait une procédure de révision.
3. Sécurité des transmissions
Vous devez protéger les RPS que vous envoyez sur le réseau et entre les différents niveaux de votre système.
C’est pourquoi vous devez imposer le HTTPS pour toutes vos communications (ou au moins pour les écrans d’inscription, toutes les pages contenant des RPS et les cookies d’autorisation). Ce protocole de communication sécurisé crypte les données avec SSL/TLS. Grâce à un algorithme spécial, il transforme les RPS en une chaîne de caractères qui n’a aucun sens sans clé de décryptage.
Un fichier appelé certificat SSL lie la clé à votre identité numérique.
Lorsqu’il établit une connexion HTTP avec votre application, le navigateur demande votre certificat. Le client vérifie alors sa crédibilité et initie ce qu’on appelle la poignée de main SSL. Le résultat est un canal de communication crypté entre l’utilisateur et votre application.
Pour activer le HTTPS pour votre application, obtenez un certificat SSL auprès de l’un des fournisseurs de confiance et installez-le correctement.
Aussi, assurez-vous d’utiliser un protocole sécurisé SSH ou FTPS pour envoyer les fichiers contenant des RPS au lieu du FTP ordinaire.
Manchette SSL ; source : the SSL store
Le courrier électronique n’est pas un moyen sécurisé d’envoyer des RPS.
Des services populaires comme Gmail ne fournissent pas la protection nécessaire. Si vous envoyez des courriels contenant des RPS au-delà de votre serveur pare-feu, vous devez les chiffrer. Il existe de nombreux services et extensions de navigateur qui peuvent le faire pour vous. Vous pouvez également utiliser un service de messagerie conforme à la loi HIPAA comme Paubox.
Vous devriez également mettre en œuvre des politiques qui limitent les informations qui peuvent être partagées par le biais de courriels.
4. Chiffrement/déchiffrement
Le chiffrement est le meilleur moyen de garantir l’intégrité des RPS. Même si des pirates parvenaient à voler vos données, elles ressembleraient à un charabia sans les clés de décryptage.
Les ordinateurs portables et autres appareils portables non cryptés sont une source courante de brèches HIPAA. Pour être du côté sûr, cryptez les disques durs de tous les appareils qui contiennent des PHI. Vous pouvez le faire avec des outils de cryptage gratuits comme BitLocker pour Windows ou FileVault pour Mac OS.
5. Elimination des RPS
Vous devez détruire définitivement les RPS lorsqu’ils ne sont plus nécessaires. Tant que sa copie demeure dans l’une de vos sauvegardes, les données ne sont pas considérées comme » éliminées « .
En 2010, Affinity Health Plan a rendu ses photocopieurs à la société de location. Il n’a cependant pas effacé leurs disques durs. La violation qui en a résulté a exposé les renseignements personnels de plus de 344 000 patients.
Affinity a dû payer 1,2 million de dollars pour cet incident.
Les renseignements personnels peuvent se cacher dans de nombreux endroits inattendus : photocopieurs, scanners, équipements biomédicaux (par exemple, appareils IRM ou à ultrasons), appareils portables (par ex.par exemple les ordinateurs portables), les vieilles disquettes, les clés USB, les DVD/CD, les cartes mémoire, la mémoire flash dans les cartes mères et les cartes réseau, la mémoire ROM/RAM, etc.
En plus d’effacer les données, vous devez également détruire correctement les supports qui contiennent des DSP avant de les jeter ou de les donner. Selon la situation, vous pouvez soit les effacer magnétiquement (par exemple en utilisant un démagnétiseur), soit écraser les données à l’aide d’un logiciel comme DBAN, soit détruire le lecteur physiquement (par exemple en le fracassant avec un marteau).
Dans les lecteurs de mémoire flash (par exemple les clés USB), les données sont réparties sur tout le support pour éviter l’usure. Pour cette raison, il est difficile d’effacer complètement les informations sensibles avec un logiciel de destruction de données ordinaire. Vous pouvez toutefois utiliser des utilitaires du fabricant comme le logiciel Samsung Magician pour vous débarrasser de vos lecteurs flash (ou simplement utiliser un marteau).
6. Sauvegarde et stockage des données
Les sauvegardes sont essentielles pour l’intégrité des données. Une corruption de la base de données ou un crash du serveur pourrait facilement endommager vos RPS. Il en va de même pour un incendie dans un centre de données ou un tremblement de terre.
C’est pourquoi il est important d’avoir plusieurs copies de vos RPS stockées à plusieurs endroits différents.
Votre plan de sauvegarde des RPS doit déterminer la probabilité de compromission des données. Toutes les informations à haut et moyen risque doivent être sauvegardées quotidiennement et stockées dans une installation sécurisée. Vous devriez également signer un BAA avec vos fournisseurs de sauvegarde.
Une sauvegarde est inutile si vous ne pouvez pas la restaurer.
En août 2016, Martin Medical Practice Concepts a été victime d’une attaque par ransomware. L’entreprise a payé les pirates pour décrypter les renseignements médicaux personnels. Mais en raison d’une défaillance de la sauvegarde, les hôpitaux locaux ont perdu des informations sur 5 000 patients.
Testez régulièrement votre système pour prévenir les échecs de récupération. Vous devez également consigner les temps d’arrêt du système et les échecs de sauvegarde des RPS.
Et n’oubliez pas que les sauvegardes elles-mêmes doivent être conformes aux normes de sécurité HIPAA.
7. Contrôles d’audit
L’absence de contrôles d’audit peut entraîner des amendes plus élevées.
Vous devez surveiller ce qui est fait aux RPS stockées dans votre système. Enregistrez chaque fois qu’un utilisateur se connecte et se déconnecte de votre système. Vous devez savoir qui, quand et où les données sensibles ont été consultées, mises à jour, modifiées ou supprimées.
La surveillance peut être effectuée par des moyens logiciels, matériels ou procéduraux. Une solution simple serait d’utiliser une table dans une base de données ou un fichier journal pour enregistrer toutes les interactions avec les informations du patient.
Cette table devrait être composée de cinq colonnes :
- user_id. L’identifiant unique de l’utilisateur qui a interagi avec les PHI;
- entity_name. L’entité avec laquelle l’utilisateur a interagi (Une entité est une représentation d’un certain concept du monde réel dans votre base de données, par exemple un dossier médical);
- record_id. L’identifiant de l’entité;
- action_type. La nature de l’interaction (création, lecture, mise à jour ou suppression);
- action_time. Le moment précis de l’interaction.
Dans cet exemple, un médecin (user_id 1) a créé le dossier d’un patient, un radiologue l’a consulté, et plus tard le même médecin a modifié le dossier.
Vous devrez vérifier périodiquement les journaux d’activité pour découvrir si certains utilisateurs abusent de leurs privilèges pour accéder aux RPS.
8. Déconnexion automatique
Un système contenant des RPS devrait automatiquement mettre fin à toute session après une période d’inactivité déterminée. Pour continuer, l’utilisateur devrait saisir à nouveau son mot de passe ou s’autoriser d’une autre manière.
Cela permettrait de protéger les RPS si quelqu’un perd son appareil alors qu’il est connecté à votre application.
La période exacte d’inactivité déclenchant la déconnexion devrait dépendre des spécificités de votre système.
Avec un poste de travail sécurisé dans un environnement hautement protégé, vous pouvez régler le minuteur sur 10-15 minutes. Pour les solutions basées sur le web, cette période ne devrait pas dépasser 10 minutes. Et pour une application mobile, vous pouvez régler le délai de 2 à 3 minutes.
Différents langages de programmation mettent en œuvre la déconnexion automatique de différentes manières.
Source : MailChimp
9. Extra-sécurité des applications mobiles
Les appareils mobiles présentent de nombreux risques supplémentaires. Un smartphone pourrait facilement être volé ou perdu dans un endroit très fréquenté, compromettant ainsi les informations sensibles.
Pour éviter cela, vous pouvez utiliser :
- Le verrouillage de l’écran (Android/iOS) ;
- Le cryptage complet de l’appareil (Android/iOS) ;
- L’effacement des données à distance (Android/iOs).
Vous ne pouvez pas imposer ces fonctionnalités aux utilisateurs, mais vous pouvez les encourager à les utiliser. Vous pouvez inclure les instructions dans votre onboarding ou envoyer des e-mails décrivant comment les activer.
Conseil : vous pouvez stocker les PHI dans un conteneur sécurisé séparément des données personnelles. De cette façon, vous pouvez effacer à distance les informations de santé sans affecter quoi que ce soit d’autre.
De nombreux médecins utilisent des smartphones personnels pour envoyer des informations de santé. Vous pouvez neutraliser cette menace avec des plateformes de messagerie sécurisée.
Ces applications hébergent les données sensibles dans une base de données sécurisée. Pour accéder aux PHI, les utilisateurs doivent télécharger la messagerie et se connecter à leur compte.
Une autre solution consiste en des portails de santé cryptés et protégés par mot de passe où les patients peuvent lire les messages de leurs médecins. Ces portails envoient des notifications sans PHI dedans (par exemple « Cher utilisateur, vous avez reçu un nouveau message de « ).
N’oubliez pas que les notifications push ne sont pas sécurisées par défaut. Elles peuvent apparaître sur l’écran même s’il est verrouillé. Veillez donc à ne pas envoyer de RPS via les notifications push. Il en va de même pour les SMS et tout message automatique.
Source : Bridge Patient Portal
Une autre chose à prendre en compte est que la FDA peut classer certaines apps mHealth comme des dispositifs médicaux (logiciels qui influencent le processus de prise de décision des professionnels de santé).
N’oubliez donc pas de vérifier si votre app doit être conforme à d’autres réglementations en matière de santé avant de commencer le développement. Vous pouvez consulter ce test de la Federal Trade Commission pour obtenir une réponse rapide.
Wrapping up
Vous avez maintenant une liste minimale de fonctionnalités pour un logiciel conforme à la loi HIPAA.
Seulement, elles ne garantiront pas sa sécurité. Elles ne vous protégeront pas contre le phishing ou l’ingénierie sociale.
Mais le fait de disposer de ces fonctionnalités devrait convaincre un auditeur que vous en avez fait assez pour protéger les données de vos clients.
Pour rendre les audits moins pénibles, documentez tous vos efforts de conformité HIPAA. Pour chaque version de votre appli, fournissez les spécifications écrites, les plans pour tester sa sécurité et leurs résultats. Et n’oubliez pas de vérifier si vous devez vous conformer à d’autres réglementations avant de commencer le développement.