Guide des normes et réglementations informatiques essentielles en matière de soins de santé

Dans les années 1980, les ERP et les EHR ont inauguré l'ère moderne de l'informatique de santé. Aujourd'hui, les soins cliniques, la sécurité des patients et l'amélioration de la qualité sont presque entièrement confiés aux ordinateurs.

Pourtant, malgré l'éventail des technologies de communication disponibles, il n'existe pas de moyen universel de gérer et de transférer les données de santé. Le principal obstacle à un échange de données fluide a été l'adoption désordonnée des normes de données de santé pour le stockage, l'encodage et le partage des informations cliniques.

Alors que le gouvernement fédéral progresse dans l'intégration des systèmes de santé, la nécessité de naviguer dans les nombreuses normes informatiques en matière de soins de santé reste ferme.

Cet article de blog répertorie les normes et réglementations informatiques vitales pour les soins de santé que les éditeurs de logiciels de santé et les organisations médicales doivent garder à l'esprit lors du développement et du déploiement de technologies de santé. Plongeons-nous !

Normes informatiques de santé régissant la sécurité des données

HIPAA

Ce qui a commencé comme une loi protégeant l'assurance maladie pour les travailleurs qui ont perdu leur emploi, HIPAA, ou Health Insurance Portability and Profitability Act, est maintenant probablement la législation la plus connue protégeant les informations sur les soins de santé. Il établit des normes pour le stockage, le partage, la gestion et l'enregistrement des informations de santé personnellement identifiables (PHI).

Ainsi, toute entité impliquée dans l'exploitation de données de santé ou la fourniture de logiciels traitant de telles données doit s'assurer que les réglementations nécessaires en matière de technologie de l'information de santé sont respectées. HIPAA se compose de plusieurs composants :

• Règle de sécurité
• Règle de confidentialité
• Règle de notification de violation
• Règle générale
• Règle d'application

Celles liées aux logiciels de santé sont les règles de sécurité, de confidentialité et de notification des violations.

Règle de sécurité HIPAA

La règle de sécurité décrit les mesures de protection pour la protection des RPS et couvre trois parties : les mesures de protection techniques, physiques et administratives.

Garanties techniques

Les garanties techniques obligent les organisations de soins de santé à crypter les RPS électroniques une fois qu'ils se déplacent au-delà des serveurs internes. Les organisations sont libres de choisir les moyens appropriés pour mettre en œuvre les exigences suivantes :

• Le contrôle d'accès (obligatoire) garantit que chaque utilisateur ayant accès aux PHI a un nom unique et un mot de passe. La norme sur les données de santé exige également la mise en place de procédures régissant la publication et la divulgation des RPS en cas d'urgence.
• L'authentification ePHI (adressable) nécessite la mise en place de mécanismes pour confirmer si les PHI ont été modifiés ou sabotés
• Le chiffrement et le déchiffrement (adressable) définit la fonctionnalité de chiffrement et de déchiffrement des messages envoyés au-delà d'un serveur interne
• Les journaux d'activité et les contrôles d'audit (obligatoires) enregistrent les tentatives d'accès aux PHI et enregistrent les modifications apportées aux données une fois qu'elles sont consultées
• Les déconnexions automatiques (adressables) empêchent de compromettre les informations personnelles sur la santé une fois qu'un appareil est laissé sans surveillance

Protections physiques

Les garanties physiques se concentrent sur la sécurisation de l'accès physique aux RPS et définissent des mesures pour sécuriser les appareils mobiles et les postes de travail. Les établissements de santé sont tenus de mettre en place :

• Contrôles d'accès aux installations (adressables)
• Lignes directrices pour l'emplacement et l'utilisation des postes de travail (obligatoire)
• Procédures d'utilisation des appareils mobiles (obligatoire)
• Politiques d'inventaire et de matériel (adressables)

Garanties administratives

Les garanties administratives établissent des mesures de haut niveau pour la protection des RPS. Ils demandent:

• Réalisation d'une évaluation des risques (obligatoire)
• Introduire une politique de gestion des risques (obligatoire)
• Formation des collaborateurs à la manipulation sécurisée des données de santé (adressable)
• Élaboration d'un plan d'urgence (obligatoire)
• Tester un plan d'urgence (adressable)
• Restreindre l'accès des tiers aux données (obligatoire)
• Signalement des incidents de sécurité (adressable)

Règle de confidentialité HIPAA

La règle de confidentialité de la norme de données de santé HIPAA décrit les mesures sur la façon dont les PHI peuvent être utilisées et divulguées. En vertu de la règle de confidentialité, les organisations de soins de santé sont censées :

• Former les employés pour s'assurer qu'ils savent quelles informations peuvent et ne peuvent pas être partagées en dehors du mécanisme de sécurité d'une organisation
• Mettre en œuvre des mesures appropriées pour maintenir l'intégrité des RPS
• Assurez-vous que les patients reçoivent une autorisation écrite avant que leurs informations médicales ne soient utilisées à des fins de marketing, de collecte de fonds ou de recherche

Règle de notification de violation HIPAA

La Breach Notification Rule exige des organisations de soins de santé qu'elles avisent les patients si leurs RPS sont compromises. Il exige également que les entités informent rapidement le ministère de la Santé et des Services sociaux des violations des PHI et émettent un avis aux médias si la violation affecte plus de cinq cents patients.

HITECH

La loi sur les technologies de l'information sur la santé pour la santé économique et clinique a été signée en 2009. La nouvelle réglementation sur les technologies de l'information dans le domaine de la santé visait à promouvoir «l'adoption et l'utilisation rationnelle des technologies de l'information sur la santé» et à renforcer l'application de la loi HIPAA. La loi oblige les prestataires de soins de santé à effectuer des audits de sécurité pour vérifier s'ils se conforment aux règles de confidentialité et de sécurité de l'HIPAA.

Ainsi, HITECH peut être considéré comme une aile d'application de HIPAA. La réglementation informatique en matière de soins de santé prévoit également des incitations financières pour les organisations de soins de santé pour annuler le coût du passage au DSE et des exigences et des sanctions plus strictes en matière de sécurité des données pour les prestataires de soins de santé et les éditeurs de logiciels. Sous HITECH, les patients doivent être informés de tout accès non autorisé à leurs données, et les informations personnelles sur la santé ne peuvent être partagées que via des méthodes sécurisées.

RGPD

Le règlement général sur la protection des données est l'une des réglementations informatiques critiques en matière de santé qui contrôle toutes les données sur les problèmes dans l'UE, et les informations sur la santé entrent dans son champ d'application. Il convient de rappeler que le RGPD s'applique non seulement aux organisations basées dans l'UE, mais également à celles en dehors de celle-ci au cas où elles cibleraient des personnes basées dans l'UE. Les étapes critiques qu'une organisation doit suivre pour assurer la conformité au RGPD couvrent :

• Nommer un Délégué à la Protection des Données dédié
• Évaluer les risques liés aux données en réalisant une analyse d'impact sur la protection des données (DPIA)
• Concevoir et déployer une stratégie de sécurité des données
• Notifier les violations de données dans les 72 heures.

Réglementation informatique de la santé contrôlant les dispositifs médicaux et les logiciels en tant que dispositifs médicaux (SaMD)

FDA

La Food and Drug Administration des États-Unis réglemente tout, des aliments aux médicaments en passant par les cosmétiques. Ce qui intéresse les fournisseurs d'informatique de santé, c'est que l'entité vérifie et établit des normes d'informatique de santé pour les dispositifs médicaux et les applications logicielles qui fonctionnent comme des dispositifs médicaux. Ainsi, si votre logiciel est impliqué dans l'exécution d'une tâche médicale et que l'utilisation involontaire de ce logiciel est liée à des risques élevés, vous devrez obtenir une autorisation de la FDA.

Un exemple de logiciel qui relève de la réglementation de la FDA pourrait inclure une application qui aide à contrôler le gonflage et le dégonflage d'un brassard de tensiomètre ou une application mobile qui dirige l'administration d'insuline sur une pompe à insuline. Vous pouvez vérifier toutes les fonctionnalités qui soumettent votre produit à l'approbation de la FDA ici.

D'autre part, si votre logiciel ne répond pas à la définition d'un dispositif médical ou présente un faible risque pour le public, il est probable que vous n'aurez pas besoin de demander l'approbation de la FDA. Les applications exclues de la certification FDA peuvent inclure des applications mobiles qui aident les patients à gérer eux-mêmes leurs conditions sans fournir de suggestions de traitement spécifiques ou celles qui aident les prestataires de soins de santé à automatiser leurs tâches quotidiennes. Pour obtenir l'approbation de la FDA,

Classer votre appareil ou SaMD

Classez votre logiciel ou votre appareil au début de votre parcours de développement d'applications de santé. Selon les caractéristiques de votre produit, celui-ci peut relever de la classe I, II ou III, qui détermine la réglementation des logiciels médicaux à exécuter. La classe à laquelle appartient un appareil dépend de son utilisation prévue et, plus important encore, de ses risques. La classe I couvre les appareils présentant le risque le plus faible et la classe III, ceux présentant le risque le plus élevé. Pour déterminer la classe de produit, vous pouvez accéder directement à la base de données de classification et rechercher l'appareil par son nom.

Vous pouvez également accéder à la liste des panels et effectuer une recherche par panel ou spécialité médicale à laquelle appartient votre appareil. De plus, étant donné que jusqu'à 74 % des dispositifs de classe I sont exemptés du processus de notification préalable à la commercialisation, vérifiez si c'est le cas avec votre produit en le recherchant sur la page des exemptions relatives aux dispositifs médicaux. Et si vous développez un dispositif médical ou un SaMD avec une utilisation prévue complètement nouvelle, nous vous recommandons de contacter directement la FDA pour discuter des réglementations en matière de technologie de l'information sur les soins de santé qui peuvent s'appliquer.

Mettre en place les contrôles nécessaires

Les dispositifs médicaux de classe I nécessitent la mise en place de contrôles généraux, à savoir :

1. Enregistrement de l'établissement et liste des dispositifs médicaux (21 CFR Part 807)
2. Réglementation du système qualité (21 CFR Part 820)
3. Exigences d'étiquetage (21 CFR Part 801)
4. Rapport sur les dispositifs médicaux (21 CFR Part 803)
5. Notification préalable à la commercialisation (21 CFR Part 807)
6. Signaler les corrections et les suppressions (21 CFR Part 806)
7. Exigences d'exemption des dispositifs expérimentaux pour les études cliniques de dispositifs expérimentaux (21 CFR Part 812)

Les dispositifs de classe II nécessitent la mise en œuvre des contrôles généraux ci-dessus, des contrôles spéciaux et une notification préalable à la commercialisation. Les dispositifs de classe III nécessitent la mise en œuvre de contrôles généraux et une approbation préalable à la commercialisation. Une fois que vous avez préparé la documentation requise, soumettez-la pour examen. Remarque : Dès le début de l'année 2022, l'entité élabore des orientations réglementant les technologies numériques de santé pour l'acquisition de données à distance et l'investigation clinique. Les directives ne sont pas encore finalisées, mais nous garderons un œil dessus.

Normes de structure du contenu des soins de santé

HL7

Développé par Health Level Seven International, une entité à but non lucratif qui fournit un cadre et des réglementations relatives aux informations sur la santé, HL7 gère l'échange de données médicales entre des systèmes de santé disparates. La norme est l'épine dorsale du DSE. Étant donné que le DSE est un système distribué qui dépend d'une interaction fluide entre plusieurs sous-systèmes pour constituer un processus de soins de santé spécifique, HL7 sert de lien entre ces sous-systèmes. Il existe deux versions de la norme informatique de santé HL7.

• HL7 version 2 : HL7 v2 convient aux systèmes de soins aux patients centralisés et aux environnements distribués où les données des patients résident dans des sous-systèmes départementaux. Avec la signature de HITECH, HL7 version 2.5.1 est spécifiquement sélectionné comme norme pour répondre à des certifications spécifiques.
• HL7 version 3 : HL7 v3 adopte une nouvelle approche de l'échange d'informations cliniques qui s'appuie sur des messages écrits en syntaxe XML. Les objectifs de HL7 v3 étaient d'augmenter l'adoption mondiale de la norme HL7, de supprimer le flou et de créer une norme plus précise, exempte de problèmes hérités. Ainsi, par rapport à la version 2 de HL7, la version 3 de HL7 présente un modèle de données cohérent et des rôles bien définis pour les applications et les messages utilisés pour différentes fonctions cliniques.

HL7 version 3 a été adopté principalement pour les applications sans exigences de communication héritées, sans utilisation historique de HL7 version2, ou dans les régions avec des exigences gouvernementales strictes pour l'utilisation de HL7 v3. Les deux versions de la norme de données de santé coexistent et il est assez courant que plusieurs versions de la norme soient déployées simultanément dans le même établissement.

Normes de transport de messages

FHIR

Basées sur HL7, les ressources d'interopérabilité Fast Healthcare décrivent les formats de données et les API pour les dossiers de santé électroniques. La norme fournit un ensemble d'API RESTful basées sur HTTP pour permettre aux prestataires de soins de santé de partager des données aux formats XML et JSON. La norme est applicable dans divers contextes, des applications mobiles aux applications cloud en passant par le partage de données basé sur le DSE. Un élément essentiel du FHIR est une ressource.

Selon son type, une ressource peut contenir des données sur les données démographiques des patients, les médicaments, les plans de soins, les allergies, etc. Lorsqu'elles sont combinées, les ressources constituent des flux de travail cliniques et administratifs variés. Malgré les réactions mitigées des prestataires de soins de santé à l'égard de la maturité du FHIR, le FHIR devrait prendre le relais d'autres normes d'échange de données de santé d'ici 2024. La raison en est que le FHIR offre la possibilité de créer des applications standardisées pour accéder aux données de santé, quel que soit le DSE qui sous-tend l'infrastructure.

DICOM

DICOM, ou Digital Images and Communications in Medicine, facilite l'échange d'images médicales et de données associées entre les logiciels et le matériel. Par rapport aux fichiers image standard, tels que JPEG ou TIFF, qui ne contiennent pas de données sur le contexte d'une image, les fichiers DICOM ont une structure plus complexe.

Ils contiennent des métadonnées qui donnent un aperçu d'un patient et des paramètres d'acquisition d'images. Les systèmes auxquels DICOM s'applique sont multiples : des scanners CT et IRM aux systèmes d'archivage et de communication d'images (PACS) en passant par les systèmes d'information radiologique (RIS).

Éléments clés à garder à l'esprit lorsqu'il s'agit de solutions de technologie de la santé

La pandémie a poussé de nombreuses organisations de soins de santé et startups de la santé à penser d'abord au numérique. En conséquence, le nombre de solutions technologiques entrant sur le marché de la santé a considérablement augmenté. En tant que fournisseur et utilisateur de technologies de santé, que pouvez-vous faire pour vous assurer que les solutions en question respectent toutes les réglementations nécessaires en matière d'informatique de santé ? Nous avons compilé une liste des conseils essentiels à garder à l'esprit.

Conseils pour les fournisseurs de technologies de la santé :

• Le développement d'une nouvelle solution technologique nécessite une compréhension approfondie des complexités et des spécificités du système de santé. Ainsi, avant de vous plonger dans la conception du produit, assurez-vous de comprendre le contexte dans lequel le produit sera utilisé, y compris les paramètres organisationnels, les groupes de parties prenantes concernés et les relations avec les parties prenantes. Il est également essentiel d'évaluer les risques associés à l'utilisation de la technologie de santé que vous développez. Connaître les risques vous aidera à définir les normes informatiques nécessaires en matière de soins de santé.
• Pour faire approuver votre produit, vous devrez soumettre tous les types de documentation aux autorités de réglementation. Ainsi, lors de la conception, de la conception et du développement de votre solution, documentez le processus de développement. Pour définir la documentation et les procédures à suivre, consultez le Département de la santé et des services sociaux, le Bureau de l'inspecteur général (OIG), la Drug Enforcement Administration (DEA) et la Food and Drug Administration (FDA).
• Avant d'entrer réellement sur le marché, envisagez d'effectuer des tests de conformité externes. Collaborer avec un fournisseur qui connaît parfaitement les réglementations en matière de logiciels de santé peut contribuer à réduire les risques lors de la mise sur le marché de votre produit.

Conseils pour les organisations de soins de santé :

Pour vous assurer que la technologie que vous utilisez est conforme à toutes les réglementations nécessaires en matière de logiciels médicaux, il est essentiel d'établir un programme de conformité complet à l'échelle de l'organisation.

• Pour ce faire, créez un comité multidisciplinaire et nommez un Chief Compliance Officer (CCO) pour guider les efforts de conformité.
• Dans un deuxième temps, laissez le comité établir les politiques, processus et calendriers nécessaires pour assurer la conformité.
• Assurez-vous que votre feuille de route de conformité comporte des audits internes et externes réguliers. Engager des auditeurs tiers dans l'examen de vos processus de conformité pourrait aider à identifier les vulnérabilités, les lacunes et les inefficacités du flux de travail.
• Pour optimiser vos efforts de conformité, déployez un solide programme de formation des employés et assurez-vous que vos employés apprennent à se conformer systématiquement aux normes informatiques de santé pertinentes.
• Enfin, assurez-vous que vos efforts portent leurs fruits en évaluant régulièrement l'efficacité de votre programme de conformité.

Au lieu d'une conclusion

Alors que la technologie de la santé approche de son élan et que les technologies innovantes telles que l'IA médicale, l'IoMT et la RPA attirent de plus en plus l'attention, les organismes de réglementation travaillent à l'élaboration des normes informatiques de santé établies. À mesure que les normes deviennent plus précises et complexes, il peut devenir assez difficile pour les startups médicales et les organisations de soins de santé de trouver ce qui est pertinent pour leur produit et de maintenir la conformité.

Donc, si vous souhaitez développer une solution de soins de santé qui vérifie toutes les cases de conformité nécessaires, contactez les experts ITRex. Nous vous aiderons à atteindre une sécurité maximale et une sécurité sans compromis.

Publié à l'origine sur https://itrexgroup.com le 22 mars 2022.