La tecnología de la salud no puede mover las imágenes a la nube. Aquí se explica cómo mantener los sistemas locales en cumplimiento.

Por qué algunos sistemas no van a ninguna parte

Cada sistema de salud está mirando hacia la nube en este momento. El almacenamiento cuesta menos, la escalabilidad es más fácil, y los proveedores siguen preguntando por qué el EMR aún no está allí. Pero entra en cualquier departamento de radiología y la respuesta es obvia: esos archivos de imágenes son enormes, y los clínicos los necesitan rápido. La mayoría de los hospitales ya ejecutan una caché local en cada sitio solo para mantener baja la latencia en las imágenes. Esa carga de trabajo no va a desaparecer.

El EMR es una decisión más difícil. Algunas organizaciones lo han migrado a la nube. Muchas no lo han hecho, porque las integraciones construidas alrededor de él (sistemas de laboratorio, farmacia, programación, interfaces de dispositivos) dependen de una baja latencia que un EMR alojado en la nube no siempre puede garantizar cuando los datos deben hacer un viaje de ida y vuelta en tiempo real. Eliminar una integración y se corre el riesgo de que un clínico mire un indicador de carga durante un encuentro en vivo con el paciente.

Y mientras los sistemas clínicos principales permanezcan en las instalaciones, Active Directory también permanece. Es la capa de identidad contra la que todo lo demás se autentica. Moverlo antes de que el resto del entorno esté listo solo añade riesgo sin eliminar ninguno.

Permanecer en las instalaciones también significa que quedarse estático no es una opción. No hay ningún proveedor de la nube que parche el sistema operativo o endurezca la configuración en segundo plano. Si un hospital mantiene un sistema internamente, todo el ciclo de vida de mantener ese sistema actualizado y seguro también permanece internamente, y demostrar que realmente está sucediendo se convierte en responsabilidad de la organización, no del proveedor.

Entonces, la realidad práctica para muchos equipos de TI de salud: la migración a la nube es real, pero parcial. Los servidores de radiología, los puntos de integración EMR y AD permanecerán en las instalaciones en el futuro previsible. Y esos sistemas aún deben cumplir con el mismo nivel de cumplimiento que todo lo demás.

Lo que HIPAA espera cuando algo sale mal

La Regla de Notificación de Violaciones de HIPAA asume lo peor por defecto. Si la información de salud protegida se usa o divulga de una manera que HIPAA no permite, la ley presume que es una violación a menos que la organización pueda documentar una evaluación de riesgos que muestre una baja probabilidad de que la PHI haya sido realmente comprometida. Esa evaluación debe considerar aspectos como qué tipo de PHI estuvo involucrada, quién accedió a ella, si fue realmente vista o adquirida, y si el riesgo fue mitigado.

Una vez que se confirma una violación, el reloj comienza. Las personas afectadas deben ser notificadas sin demora indebida y a más tardar 60 días después del descubrimiento. Las violaciones que afectan a 500 o más personas también requieren notificación al HHS dentro de los 60 días, además de la notificación a los medios en algunos casos. Las violaciones menores se incluyen en un informe anual al HHS.

Esta es la parte que más importa para un servidor de radiología local o una caja de integración EMR: la organización debe poder reconstruir lo que sucedió. Quién tocó el archivo. Cuándo. Si el cambio era esperado. Sin eso, la evaluación de riesgos por defecto es "no lo sabemos", y "no lo sabemos" por defecto es una violación reportable.

Los registros por sí solos no resistirán una auditoría

Los sistemas locales cambian constantemente: parches, ediciones de configuración, nuevas cuentas, un ingeniero del proveedor accediendo remotamente a una interfaz PACS a las 2 a.m. para arreglar una cola de impresión. La mayoría de eso está bien. Parte no está autorizada en absoluto, y los registros nativos del sistema operativo no te dicen cuál es cuál. Te dicen que una clave del registro cambió. No te dicen si ese cambio coincidió con un ticket aprobado o vino de alguien que no debería haber tenido acceso.

Entonces, cuando OCR o un auditor preguntan si un servidor de interfaz EMR específico fue modificado el último trimestre, la respuesta honesta para muchos equipos es "tendríamos que ir a verificar." No es un buen lugar para estar cuando el reloj para determinar una violación ya está corriendo.

Construyendo evidencia de auditoría sin aumentar el personal

Netwrix Change Tracker ofrece a la informática sanitaria una forma de mantener la integridad en los sistemas que deben permanecer en las instalaciones, incluidos los servidores de radiología, los puntos de integración EMR y la infraestructura de Active Directory que no se moverán.

Construye una línea base conocida y confiable para esos sistemas, luego supervisa la integridad de los archivos y el estado de la configuración en tiempo real en Windows, Linux y los dispositivos de red entre ellos. Cuando algo cambia, ya sea una clave de registro, un archivo de configuración o una cuenta local, Change Tracker lo verifica contra los Cambios Planificados aprobados. Si coincide con una ventana de cambio aprobada, se registra como una actividad esperada. Si no, se marca inmediatamente, y TI lo sabe en minutos en lugar de descubrirlo durante una auditoría o una revisión de incidentes.

Eso significa que "tendríamos que ir a comprobar" se convierte en "aquí está." El registro ya muestra qué cambió, cuándo y si fue autorizado, y ese es la mayor parte del trabajo detrás de una evaluación de riesgo defendible de cuatro factores.

Rastreador de Cambios también incluye más de 250 informes de cumplimiento preconstruidos mapeados a marcos como HIPAA, NIST, y PCI DSS, por lo que demostrar que el control estaba en su lugar no significa construir un informe desde cero en cada ciclo de auditoría. La evidencia ya está estructurada de la manera en que un auditor espera verla.

La conversación sobre la nube en TI de salud no ha terminado, y no debería hacerlo. Pero los sistemas que permanecen en las instalaciones aún deben demostrar que están bajo control. Change Tracker ofrece a los equipos de TI y cumplimiento una forma de hacerlo sin esperar a que el resto de la infraestructura se ponga al día.