Le cadre d’échange de confiance et l’accord commun, créés par le Bureau du coordonnateur national pour l’informatique de la santé dans le cadre de la loi sur les remèdes du 21e siècle, sont extrêmement prometteurs en matière d’interopérabilité et d’échange d’informations.
Cela a également de grandes implications en matière de confidentialité et de sécurité.
« Il est possible qu’un incident de sécurité TEFCA soit également un incident de sécurité HIPAA, et il est possible qu’un incident de sécurité HIPAA soit ou non un incident de sécurité TEFCA », a déclaré Johnathan Coleman, directeur de Security Risk Solutions et responsable de la sécurité de l’information chez le projet Sequoia, l’entité de coordination reconnue de TEFCA.
Lors de l’HIMSS24, le mois dernier, Coleman, aux côtés de Zoe Barber, directrice politique de Sequoia, a donné un aperçu des flux de réponse aux incidents et de signalement des incidents de TEFCA, en se concentrant sur le développement de domaines susceptibles de faire trébucher des entités non couvertes par la HIPAA.
Nouvelle agilité, nouvelles exigences de sécurité
Barber a déclaré que les exigences garantissant l’échange de données protégé dans le cadre de TEFCA ne connaîtraient pas de mises à jour significatives dans la deuxième version à venir de l’accord commun.
« Les obligations en matière de confidentialité et de sécurité s’appliquent à tous, et elles sont cohérentes dans l’ensemble du cadre », a-t-elle déclaré lors d’un bref aperçu de TEFCA avant que Coleman ne se penche sur les nuances des rapports d’incidents de cybersécurité de TEFCA.
Alors que Sequoia, en tant que RCE, facilite l’échange de données en simplifiant la façon dont les participants se connectent au réseau, sous TEFCA, un participant individuel peut utiliser une application de son choix pour demander l’accès à ses informations de santé.
Depuis que le Bureau du coordinateur national pour l’informatique de santé a rédigé la proposition d’interopérabilité TEFCA, il est également devenu plus facile pour les principaux délégués – un fournisseur, un échange d’informations sur la santé ou un autre associé commercial travaillant pour les autorités principales qui fournissent des services cliniques et conservent les données des patients – d’échanger et simplifier leur connexion au réseau, a expliqué Barber.
Créer plus d’agilité pour les participants signifie que l’échange ne se limite pas entre QHIN et QHIN, mais que l’interopérabilité peut se produire directement entre les participants via des API.
« Auparavant, nous avions une exigence assez stricte selon laquelle vous ne pouviez participer qu’avec un seul (réseau d’information sur la santé qualifié), mais maintenant nous ouvrons un peu cette limite pour permettre la participation entre plusieurs QIHIN – à condition que vous utilisiez un réseau d’information sur la santé différent. système », a-t-elle déclaré.
Cryptage pour les HIE, BA et autres
Les changements visant à soutenir une utilisation plus large des transactions basées sur les ressources d’interopérabilité rapide des soins de santé de Health Level Seven ont entraîné des mises à jour de la terminologie dans les normes de pratique de la TEFCA, a noté Barber.
Les projets de mises à jour de TEFCA ont été publiés pour commentaires publics en janvier et la période de commentaires s’est clôturée en février. Micky Tripathi, coordinateur national de l’ONC, a déclaré SantéITActualités en janvier, que l’arrivée de TEFCA 2.0 interviendrait au début de la feuille de route d’interopérabilité 2024 de l’ONC.
Pour permettre l’échange FHIR, le RCE exige une preuve d’identité à deux niveaux, a noté Coleman.
«Ils doivent utiliser une application qui a un contrat et une relation de travail avec le fournisseur de services d’identification afin que le niveau de sécurité approprié puisse être appliqué à ces transactions lorsqu’ils demandent ensuite leurs informations de santé via le réseau TEFCA et qu’ils reçoivent une réponse. , » il a dit.
De plus, pour les fournisseurs de services d’accès individuels qui ne sont pas nécessairement des entités couvertes par la HIPAA, comme un associé commercial, « nous voulions nous assurer que les informations individuellement identifiables qu’une organisation de fournisseur de services d’accès individuel stocke, conserve et utilise dans ce rôle sont crypté à la fois au repos et en transit.
Protocoles de signalement d’incidents
Coleman a déclaré que pour le reporting des incidents, il sera essentiel pour ces entités de savoir si elles doivent suivre le protocole de reporting des incidents de sécurité TEFCA ainsi que les protocoles de reporting des incidents HIPAA qu’elles ont mis en place, « ou si elles se contentent de suivre, par exemple. , les protocoles de signalement d’incidents HIPAA.
Il existe quatre exclusions modélisées « de manière similaire » aux règles de sécurité HIPAA – « des solutions qui existent, qui ne sont en aucun cas destinées à les remplacer », a-t-il déclaré.
« Tous les QHIN doivent respecter la règle de sécurité HIPAA, tout comme les participants et sous-participants, même s’ils ne sont pas une entité HIPAA », a-t-il déclaré, et il existe des exigences supplémentaires pour la couverture de cybersécurité du QHIN qui doivent être certifiées par un organisme indépendant. tierce personne.
La certification HITRUST, par exemple, est « extrêmement complète, longue et très approfondie », notamment en ce qui concerne les exigences de maintien de la certification.
« Ce n’est pas une mince affaire », a déclaré Coleman.
Les RLISS « doivent avancer activement sur tout ce qui figure dans leur plan d’action corrective ou leur plan d’action et leurs jalons, et ils doivent s’attaquer aux faiblesses identifiées », a-t-il déclaré.
Ils sont également tenus de partager ces informations avec les participants et sous-participants, « afin que collectivement, l’écosystème technologique puisse commencer à réellement faire progresser les meilleures pratiques de sécurité et à mettre en œuvre ces meilleures pratiques de sécurité ».
Pour une entité non couverte par la HIPAA, « ce sont toutes les informations individuellement identifiables qu’elle conserve, pas seulement les informations TEFCA », a déclaré Coleman.
« Parce qu’ils n’ont pas d’OCR qui surveille leurs épaules… nous voulons nous assurer qu’ils font ce qu’il faut et qu’ils chiffrent leurs informations de santé en danger et en transit. »
Lorsqu’un participant affecté par un incident de sécurité TEFCA fait le rapport requis sur cet incident à son QHIN, « le QHIN aurait l’obligation de le signaler au RCE et aux autres QHIN touchés par la violation ou par l’incident. », a expliqué Coleman.
De plus, les entités concernées devraient faire rapport, en informant leurs participants et sous-participants. Ces exigences de flux descendant de la TEFCA garantissent que « nous obtenons une bonne communication – en temps opportun – afin que ceux qui ont besoin de savoir soient informés dès que possible », a-t-il déclaré.
Incident TEFCA, incident HIPAA ou les deux ?
Bien qu’ils soient toujours considérés comme des travaux en cours, Coleman a partagé les ressources du projet Sequoia pour identifier les types d’incidents de sécurité pour les entités non couvertes par la HIPAA.
Si un incident a affecté des informations identifiables individuellement et que les informations n’ont pas été cryptées, « alors il s’agit automatiquement d’un incident de sécurité TEFCA », a-t-il déclaré.
« Non seulement il y a un incident de sécurité chez TEFCA, mais ils violent également leurs conditions de participation au sein de TEFCA parce qu’ils n’ont pas réussi à chiffrer en transit et au repos », a-t-il déclaré. « C’est un grand non-non. »
En attendant, si les informations d’identification individuelle étaient cryptées, il pourrait toujours s’agir d’un incident de sécurité TEFCA, a-t-il déclaré.
C’est lorsqu’un incident affecte des données de santé et que ces données ont été incorporées dans un système comme les dossiers de santé électroniques, « selon les définitions, ce ne sont plus des informations TEFCA », a précisé Coleman. « Maintenant, ce sont des informations HIPAA, n’est-ce pas ? »
Il a ensuite expliqué comment un incident pourrait être un incident de sécurité TEFCA – même s’il n’implique pas d’informations TEFCA.
« Si cela affecte négativement la capacité de cette organisation à participer à l’échange TEFCA, si elle n’est plus en mesure de répondre aux requêtes – même si rien n’a été divulgué selon la définition des informations TEFCA – cela affecte toujours sa capacité à participer. »
Il existe tout un « arbre de décision violet » pour ce protocole, qui guide les utilisateurs si l’incident répond à l’une des exceptions TEFCA, par exemple lorsqu’un médecin envoie des informations au mauvais médecin.
« Ils sont tous deux autorisés à recevoir des informations sur les soins de santé », a déclaré Coleman. Lorsque le prestataire destinataire ne fait rien d’autre avec les informations du patient et qu’il les clarifie, il ne s’agit pas d’un incident TEFCA.
« Cependant, s’il ne répond pas à l’une de ces exceptions et tombe également dans le seuil d’autres incidents de sécurité ou d’autres incidents à signaler, alors c’est quelque chose que nous voudrions connaître », a-t-il déclaré. « Cela devient donc un incident de sécurité TEFCA, ainsi qu’un incident de sécurité HIPAA », pour lequel une notification en double aux patients individuels concernés ne serait pas nécessaire.
Andrea Fox est rédactrice en chef de Healthcare IT News.
Courriel : afox@himss.org
Healthcare IT News est une publication HIMSS Media.