L'informatique de santé ne peut pas déplacer l'imagerie vers le cloud. Voici comment maintenir la conformité des systèmes sur site.

Pourquoi certains systèmes n'avancent pas

Chaque système de santé regarde actuellement vers le cloud. Le stockage coûte moins cher, la montée en charge est plus facile, et les fournisseurs demandent sans cesse pourquoi le DME n'y est pas encore. Mais entrez dans n'importe quel service de radiologie et la réponse est évidente : ces fichiers d'imagerie sont énormes, et les cliniciens en ont besoin rapidement. La plupart des hôpitaux exécutent déjà un cache local sur chaque site juste pour réduire la latence des images. Cette charge de travail ne va nulle part.

Le DME est un choix plus difficile. Certaines organisations l'ont migré vers le cloud. Beaucoup ne l'ont pas fait, car les intégrations construites autour de lui (systèmes de laboratoire, pharmacie, planification, interfaces de dispositifs) dépendent d'une faible latence qu'un DME hébergé dans le cloud ne peut pas toujours garantir lorsque les données doivent faire un aller-retour en temps réel. Supprimer une intégration et vous risquez qu'un clinicien regarde un indicateur de chargement pendant une consultation en direct avec un patient.

Et tant que les systèmes cliniques principaux restent sur site, Active Directory reste aussi. C'est la couche d'identité contre laquelle tout le reste s'authentifie. Le déplacer avant que le reste de l'environnement soit prêt ajoute simplement des risques sans en éliminer.

Rester sur site signifie également que rester statique n'est pas une option. Il n'y a pas de fournisseur cloud qui applique silencieusement des correctifs au système d'exploitation ou renforce la configuration en arrière-plan. Si un hôpital garde un système en interne, tout le cycle de vie pour maintenir ce système à jour et sécurisé reste également en interne, et prouver que cela se produit réellement devient la responsabilité de l'organisation, pas du fournisseur.

Ainsi, la réalité pratique pour de nombreuses équipes informatiques de santé : la migration vers le cloud est réelle, mais partielle. Les serveurs de radiologie, les points d'intégration EMR et AD restent sur site pour un avenir prévisible. Et ces systèmes doivent toujours respecter les mêmes normes de conformité que tout le reste.

Ce que HIPAA attend lorsqu'il y a un problème

La règle de notification des violations HIPAA part du principe du pire par défaut. Si des informations de santé protégées sont utilisées ou divulguées d'une manière non autorisée par HIPAA, la loi présume qu'il s'agit d'une violation à moins que l'organisation puisse documenter une évaluation des risques montrant une faible probabilité que les PHI aient réellement été compromises. Cette évaluation doit prendre en compte des éléments tels que le type de PHI impliqué, qui y a eu accès, si elles ont réellement été consultées ou acquises, et si le risque a été atténué.

Une fois qu'une violation est confirmée, le compte à rebours commence. Les personnes concernées doivent être informées sans délai déraisonnable et au plus tard 60 jours après la découverte. Les violations affectant 500 personnes ou plus nécessitent également une notification au HHS dans les 60 jours, ainsi qu'une notification aux médias dans certains cas. Les violations plus petites sont incluses dans un rapport annuel au HHS.

Voici la partie la plus importante pour un serveur de radiologie sur site ou une boîte d'intégration EMR : l'organisation doit être capable de reconstruire ce qui s'est passé. Qui a touché le fichier. Quand. Si le changement était prévu. Sans cela, l'évaluation des risques revient à "nous ne savons pas", et "nous ne savons pas" revient à une violation à signaler.

Les journaux seuls ne suffiront pas lors d'un audit

Les systèmes sur site changent constamment : correctifs, modifications de configuration, nouveaux comptes, un ingénieur fournisseur se connectant à distance à une interface PACS à 2 heures du matin pour réparer une file d'impression. La plupart de ces changements sont normaux. Certains ne sont pas du tout autorisés, et les journaux natifs du système d'exploitation ne vous disent pas lesquels. Ils vous indiquent qu'une clé de registre a changé. Ils ne vous disent pas si ce changement correspondait à un ticket approuvé ou provenait de quelqu'un qui n'aurait pas dû avoir accès.

Donc, lorsque l'OCR ou un auditeur demande si un serveur d'interface EMR spécifique a été modifié le trimestre dernier, la réponse honnête pour beaucoup d'équipes est « nous devrions aller vérifier ». Ce n'est pas une bonne position lorsque le temps pour déterminer une violation est déjà lancé.

Constituer des preuves d'audit sans augmenter les effectifs

Netwrix Change Tracker offre à l’informatique de santé un moyen de garantir l’intégrité des systèmes qui doivent rester sur site, y compris les serveurs de radiologie, les points d’intégration EMR et l’infrastructure Active Directory qui ne vont nulle part.

Il établit une base de référence fiable pour ces systèmes, puis surveille en temps réel l'intégrité des fichiers et l'état de la configuration sur Windows, Linux et les appareils réseau entre eux. Lorsqu'un changement survient, qu'il s'agisse d'une clé de registre, d'un fichier de configuration ou d'un compte local, Change Tracker le vérifie par rapport aux Changements Planifiés approuvés. S'il correspond à une fenêtre de changement approuvée, il est enregistré comme une activité attendue. Sinon, il est immédiatement signalé, et l'informatique est informée en quelques minutes au lieu de le découvrir lors d'un audit ou d'un examen d'incident.

Cela signifie que « nous devrions vérifier » devient « le voici ». Le registre montre déjà ce qui a changé, quand, et si cela a été autorisé, et c’est la majeure partie du travail derrière une évaluation des risques défendable à quatre facteurs.

Change Tracker est également livré avec plus de 250 rapports de conformité préconstruits mappés à des cadres tels que HIPAA, NIST, et PCI DSS, donc prouver que le contrôle était en place ne signifie pas construire un rapport à partir de zéro à chaque cycle d'audit. Les preuves sont déjà structurées de la manière dont un auditeur s'attend à les voir.

La conversation sur le cloud dans l'informatique de santé n'est pas terminée, et elle ne devrait pas l'être. Mais les systèmes restant sur site doivent encore prouver qu'ils sont sous contrôle. Change Tracker offre aux équipes informatiques et de conformité un moyen de le faire sans attendre que le reste de l'infrastructure rattrape son retard.