Cómo hacer que su aplicación sanitaria cumpla la HIPAA

Entre otras cosas, la HIPAA protege la información sanitaria de los pacientes.

Anthem, la mayor compañía de seguros de EE.UU., aprendió esto por las malas.

Lo que empezó con un simple correo electrónico de phishing, llevó a la mayor violación de datos sanitarios de la historia. Los hackers robaron los datos de 79 millones de pacientes. La información incluía sus nombres, números de la seguridad social e identificaciones médicas.

Los enfurecidos pacientes demandaron a Anthem y obtuvieron un acuerdo de 115 millones de dólares. Aunque la compañía evitó las multas del regulador, tendría que gastar hasta 260 millones de dólares para mejorar su seguridad.

La Oficina de Derechos Civiles (OCR) del HHS supervisa el cumplimiento de la HIPAA. Solo en 2017 ha multado a los proveedores de servicios sanitarios estadounidenses con casi 20 millones de dólares.

Incluso si se trata de una organización pequeña, descuidar los requisitos de la HIPAA puede acarrear graves problemas.

En 2013 Fresenius Medical Care North America sufrió cinco violaciones de datos. Combinadas, expusieron los datos de sólo 525 pacientes. Pero la empresa tuvo que pagar una monstruosa multa de 3,5 millones de dólares porque no analizó adecuadamente los riesgos de seguridad.

Según el grado de negligencia, hay cuatro tipos de multas de la HIPAA:

Glosario de la HIPAA

Debe entender estos tres términos clave antes de abordar los requisitos de la HIPAA.

• Información sanitaria protegida (PHI): cualquier dato que pueda utilizarse para identificar a un paciente.

La PHI consta de dos partes: información sanitaria e identificadores personales. Estos últimos incluyen los nombres de los pacientes, direcciones, fechas de nacimiento, números de la seguridad social, historiales médicos, fotos, etc. El hecho de que un individuo haya recibido servicios médicos es una IPS en sí misma.

¿Qué se considera IPS? La lista completa.

• Entidades cubiertas: organizaciones e individuos que ofrecen servicios/operaciones de asistencia sanitaria, o que aceptan pagos por ellos.

Incluyen a todos los proveedores de asistencia sanitaria (por ejemplo, hospitales, médicos, dentistas, psicólogos), planes de salud (por ejemplo, proveedores de seguros, HMO, programas gubernamentales como Medicare y Medicaid) y cámaras de compensación (las organizaciones que actúan como intermediarios entre los proveedores de asistencia sanitaria y las compañías de seguros).

• Asociados comerciales – los terceros que manejan la PHI en nombre de las entidades cubiertas.

Esta categoría incluye a los desarrolladores de aplicaciones de atención médica, proveedores de alojamiento/almacenamiento de datos, servicios de correo electrónico, etc.

De acuerdo con la HIPAA, usted debe firmar un Acuerdo de Asociado Comercial (BAA) con cada parte que tenga acceso a su PHI. La decisión de no firmar un BAA no le exime de los requisitos de la HIPAA.

Puede haber muchas formas no intencionadas en las que los datos sensibles pueden entrar en su sistema.

Tomemos, por ejemplo, un servicio que permite a los médicos diagnosticar las condiciones de la piel basándose en fotos anónimas. La aplicación no maneja PHI ya que no puede identificar a sus usuarios. Pero en cuanto añade el nombre o la dirección de la persona a las fotos, éstas se convierten en PHI.

Si su aplicación recopila, almacena o transmite PHI a las entidades cubiertas, debe cumplir con la HIPAA.

¿Cómo cumplir con la HIPAA?

Para cumplir con la HIPAA, tendrá que realizar evaluaciones periódicas, tanto técnicas como no técnicas, de sus esfuerzos para proteger la información sanitaria y documentarlas exhaustivamente. El organismo regulador ha publicado un modelo de protocolo de auditoría que puede ayudarle a evaluar el cumplimiento de la HIPAA.

Puede contratar a un auditor independiente para que realice la evaluación por usted. Hay muchas organizaciones como HITRUST que se especializan en ese tipo de cosas. Sólo recuerde que la OCR no reconoce los certificados de terceros.

Protecciones técnicas. Medidas de seguridad como el inicio de sesión, el cifrado, el acceso de emergencia, los registros de actividad, etc. La ley no especifica qué tecnologías debe utilizar para proteger la PHI.

Las Salvaguardas Físicas tienen como objetivo asegurar las instalaciones y los dispositivos que almacenan la PHI (servidores, centros de datos, PCs, portátiles, etc.).

Con las modernas soluciones basadas en la nube, esta regla se aplica principalmente al alojamiento que cumple con la HIPAA.

La ley se aplica a una amplia gama de software médico. Un sistema de gestión hospitalaria (HMS) difiere radicalmente de las aplicaciones de diagnóstico remoto. Pero hay algunas características que son esenciales para todas las apps que cumplen con la HIPAA.

Así que aquí hay una lista mínima de características requeridas para el software que cumple con la HIPAA:

1. Control de acceso

Cualquier sistema que almacene PHI debe limitar quién puede ver o modificar los datos sensibles. Según la regla de privacidad de la HIPAA, nadie debe ver más información del paciente que la necesaria para realizar su trabajo. La regla también especifica la desidentificación, los derechos del paciente a ver sus propios datos y su capacidad para dar o restringir el acceso a su PHI.

Una forma de lograr esto es asignar a cada usuario una identificación única. Esto le permitiría identificar y rastrear la actividad de las personas que acceden a su sistema.

Luego, tendrá que dar a cada usuario una lista de privilegios que le permitan ver o modificar cierta información. Puede regular el acceso a entidades individuales de la base de datos y URLs.

En su forma más simple, el control de acceso basado en el usuario consiste en dos tablas de la base de datos. Una tabla contiene la lista de todos los privilegios y sus identificadores. La segunda tabla asigna estos privilegios a usuarios individuales.

En este ejemplo, el médico (ID de usuario 1) puede crear, ver y modificar las historias clínicas, mientras que el radiólogo (ID de usuario 2) sólo puede actualizarlas.
Un control de acceso basado en roles es otra forma de implementar este requisito. Con él, puede asignar privilegios a diferentes grupos de usuarios en función de su posición (por ejemplo, médicos, técnicos de laboratorio, administradores).

2. Autenticación de personas o entidades

Después de haber asignado privilegios, su sistema debe ser capaz de verificar que la persona que intenta acceder a la PHI es la que dice ser. La ley ofrece varias formas generales de implementar esta salvaguarda:

Una contraseña es uno de los métodos de autenticación más sencillos. Lamentablemente, también es uno de los más fáciles de descifrar. Según Verizon, el 63% de las violaciones de datos se deben a contraseñas débiles o robadas. Otro informe afirma que una quinta parte de los usuarios corporativos tienen contraseñas fácilmente comprometidas.

Por otro lado, una contraseña verdaderamente segura:

• Consta de al menos 8-12 caracteres que incluyen letras mayúsculas, números y caracteres especiales;
• Excluye las combinaciones más utilizadas (por ejemplo «password», «123456», «qwerty», y por alguna inexplicable razón «monkey») y palabras de vocabulario;
• Descarta cualquier variación del nombre de usuario;
• Previene la reutilización de la contraseña.

Alternativamente, podría ser una cadena de palabras aleatorias aplastadas como un polo de hormigón.

Su aplicación podría comprobar estos requisitos en la pantalla de registro y denegar el acceso a los usuarios con contraseñas débiles.

No existe tal cosa como demasiada seguridad. Fuente: mailbox.org

Algunas organizaciones obligan a sus empleados a cambiar las contraseñas cada 90 días aproximadamente. Hacer esto con demasiada frecuencia puede perjudicar sus esfuerzos de seguridad. Cuando se les obliga a cambiar las contraseñas, la gente suele idear combinaciones poco originales (por ejemplo, contraseña ⇒ pa$$palabra).

Además, los piratas informáticos pueden descifrar una mala contraseña en cuestión de segundos y utilizarla inmediatamente.

Por eso debería considerar la posibilidad de utilizar una autenticación de dos factores. Estos sistemas combinan una contraseña segura con un segundo método de verificación. Puede ser cualquier cosa, desde un escáner biométrico hasta un código de seguridad de un solo uso recibido por SMS.

La idea es sencilla: incluso si los hackers obtuvieran de algún modo su contraseña, necesitarían robar su dispositivo o sus huellas dactilares para acceder a la PHI.

Pero la autenticación segura no es suficiente. Algunos atacantes podrían interponerse entre el dispositivo del usuario y sus servidores. De esta manera, los hackers podrían acceder a la PHI sin comprometer la cuenta. Esto se conoce como secuestro de sesión, un tipo de ataque man-in-the-middle.

Una de las posibles formas de secuestrar una sesión. Fuente: Heimdal Security

La firma digital es una forma de defenderse de este tipo de ataques. Volver a introducir la contraseña al firmar un documento probaría la identidad del usuario.

A medida que los roles en su sistema se vuelven más complejos, la autorización de la HIPAA puede obstaculizar la ayuda a los pacientes. Tiene sentido implementar el acceso de emergencia. Estos procedimientos permiten a los usuarios autorizados ver cualquier dato que necesiten cuando la situación lo requiera.

Un médico podría, por ejemplo, acceder a la PHI de cualquier paciente en caso de emergencia. Al mismo tiempo, el sistema notificaría automáticamente a varias otras personas e iniciaría un procedimiento de revisión.

3. Seguridad en la transmisión

Debe proteger la PHI que envía a través de la red y entre los diferentes niveles de su sistema.

Por eso debe forzar el uso de HTTPS para todas sus comunicaciones (o al menos para las pantallas de registro, todas las páginas que contienen PHI y las cookies de autorización). Este protocolo de comunicación segura encripta los datos con SSL/TLS. Mediante un algoritmo especial, convierte la PHI en una cadena de caracteres que no tiene sentido sin las claves de descifrado.

Un archivo llamado certificado SSL vincula la clave a su identidad digital.

Al establecer una conexión HTTP con su aplicación, el navegador solicita su certificado. A continuación, el cliente comprueba su credibilidad e inicia el llamado handshake SSL. El resultado es un canal de comunicación cifrado entre el usuario y tu aplicación.

Para habilitar HTTPS para tu aplicación, consigue un certificado SSL de uno de los proveedores de confianza e instálalo correctamente.

Además, asegúrese de utilizar un protocolo seguro SSH o FTPS para enviar los archivos que contengan PHI en lugar del FTP habitual.

Hacer un apretón de manos SSL; fuente: the SSL store

El correo electrónico no es una forma segura de enviar PHI.

Servicios populares como Gmail no proporcionan la protección necesaria. Si envía correos electrónicos que contengan PHI más allá de su servidor con firewall, debe cifrarlos. Hay muchos servicios y extensiones de navegador que pueden hacer esto por usted. Como alternativa, puede utilizar un servicio de correo electrónico que cumpla con la HIPAA, como Paubox.

También debe implementar políticas que limiten la información que se puede compartir a través de los correos electrónicos.

4. Cifrado/descifrado

El cifrado es la mejor manera de garantizar la integridad de la PHI. Incluso si los piratas informáticos consiguieran robar sus datos, parecerían un galimatías sin las claves de descifrado.

Los ordenadores portátiles sin cifrar y otros dispositivos portátiles son una fuente común de violaciones de la HIPAA. Para estar seguro, cifre los discos duros de todos los dispositivos que contengan PHI. Puede hacerlo con herramientas de cifrado gratuitas como BitLocker para Windows o FileVault para Mac OS.

5. Eliminación de la PHI

Debe destruir permanentemente la PHI cuando ya no la necesite. Mientras su copia permanezca en una de sus copias de seguridad, los datos no se consideran «eliminados».

En 2010 Affinity Health Plan devolvió sus fotocopiadoras a la empresa de leasing. Sin embargo, no borró sus discos duros. La infracción resultante expuso la información personal de más de 344.000 pacientes.

Affinity tuvo que pagar 1,2 millones de dólares por este incidente.

La información personal puede esconderse en muchos lugares inesperados: fotocopiadoras, escáneres, equipos biomédicos (por ejemplo, máquinas de resonancia magnética o de ultrasonidos), dispositivos portátiles (por ejemplo, ordenadores portátiles), viejos discos duros, etc.p. ej., ordenadores portátiles), viejos disquetes, unidades flash USB, DVDs/CDs, tarjetas de memoria, memoria flash en placas base y tarjetas de red, memoria ROM/RAM, etc.

Además de borrar los datos, también debe destruir adecuadamente los soportes que contienen PHI antes de tirarlos o regalarlos. Dependiendo de la situación, puede borrarlos magnéticamente (por ejemplo, utilizando un desmagnetizador), sobrescribir los datos utilizando un software como DBAN o destruir la unidad físicamente (por ejemplo, rompiéndola con un martillo).

En las unidades de memoria flash (por ejemplo, las memorias USB), los datos se reparten por todo el soporte para evitar el desgaste. Por ello, es difícil borrar completamente la información sensible con un software normal de destrucción de datos. Sin embargo, puede utilizar utilidades del fabricante como Samsung Magician Software para deshacerse de sus unidades flash (o simplemente utilizar un martillo).

6. Copia de seguridad y almacenamiento de datos

Las copias de seguridad son esenciales para la integridad de los datos. Una corrupción de la base de datos o una caída del servidor podría dañar fácilmente su PHI. También lo hace un incendio en un centro de datos o un terremoto.

Por eso es importante tener varias copias de su PHI almacenadas en varios lugares diferentes.

Su plan de copias de seguridad de la PHI debe determinar la probabilidad de que los datos se vean comprometidos. Toda la información de alto y medio riesgo debe ser objeto de una copia de seguridad diaria y almacenada en una instalación segura. También debe firmar un BAA con sus proveedores de copias de seguridad.

Una copia de seguridad no sirve de nada si no se puede restaurar.

En agosto de 2016, Martin Medical Practice Concepts fue víctima de un ataque de ransomware. La empresa pagó a los hackers para desencriptar la PHI. Pero debido a un fallo en la copia de seguridad, los hospitales locales perdieron la información de 5.000 pacientes.

Prueba tu sistema con regularidad para prevenir fallos de recuperación. También debe registrar el tiempo de inactividad del sistema y cualquier fallo en las copias de seguridad de la PHI.

Y recuerde que las propias copias de seguridad deben cumplir con las normas de seguridad de la HIPAA.

7. Controles de auditoría

La ausencia de controles de auditoría podría dar lugar a multas más elevadas.

Debe supervisar lo que se hace con la PHI almacenada en su sistema. Registre cada vez que un usuario entre y salga de su sistema. Debe saber quién, cuándo y dónde se ha accedido, actualizado, modificado o eliminado los datos sensibles.

La supervisión puede realizarse mediante software, hardware o medios de procedimiento. Una solución sencilla sería utilizar una tabla en una base de datos o un archivo de registro para registrar todas las interacciones con la información del paciente.

Dicha tabla debería constar de cinco columnas:

• user_id. El identificador único del usuario que ha interactuado con la IPS;
• nombre_entidad. La entidad con la que el usuario ha interactuado (Una entidad es una representación de algún concepto del mundo real en su base de datos, por ejemplo, un registro sanitario);
• record_id. El identificador de la entidad;
• tipo de acción. La naturaleza de la interacción (crear, leer, actualizar o eliminar);
• action_time. El momento preciso de la interacción.

En este ejemplo, un médico (user_id 1) ha creado el registro de un paciente, un radiólogo lo ha visto, y más tarde el mismo médico ha modificado el registro.

Tendrá que auditar periódicamente los registros de actividad para descubrir si algunos usuarios abusan de sus privilegios para acceder a la PHI.

8. Cierre de sesión automático

Un sistema con PHI debería terminar automáticamente cualquier sesión después de un período de inactividad establecido. Para continuar, el usuario tendría que volver a introducir su contraseña o autorizarse de alguna otra manera.

Esto protegería la PHI si alguien pierde su dispositivo mientras está conectado a su aplicación.

El período exacto de inactividad que desencadena el cierre de sesión debería depender de las características específicas de su sistema.

Con una estación de trabajo segura en un entorno altamente protegido, puede establecer el temporizador para 10-15 minutos. Para las soluciones basadas en la web, este período no debería superar los 10 minutos. Y para una aplicación móvil, puede establecer el tiempo de espera para 2-3 minutos.

Diferentes lenguajes de programación implementan el cierre de sesión automático de diferentes maneras.

Fuente: MailChimp

9. Aplicación móvil extra-seguridad

Los dispositivos móviles presentan muchos riesgos adicionales. Un smartphone puede ser fácilmente robado o perdido en una zona muy transitada comprometiendo la información sensible.

Para evitarlo, se puede utilizar:

• Bloqueo de pantalla (Android/iOS);
• Encriptación completa del dispositivo (Android/iOS);
• Borrado remoto de datos (Android/iOs).

No puedes obligar a los usuarios a utilizar estas funciones, pero puedes animarles a que las usen. Puede incluir las instrucciones en su onboarding o enviar correos electrónicos describiendo cómo habilitarlas.

Consejo: Puede almacenar la PHI en un contenedor seguro separado de los datos personales. De este modo, puede borrar de forma remota la información sanitaria sin afectar a nada más.

Muchos médicos utilizan smartphones personales para enviar información sanitaria. Se puede neutralizar esta amenaza con plataformas de mensajería segura.

Estas aplicaciones alojan los datos sensibles en una base de datos segura. Para acceder a la PHI, los usuarios tienen que descargarse el programa de mensajería e iniciar sesión en sus cuentas.

Otra solución son los portales de salud encriptados y protegidos por contraseña en los que los pacientes pueden leer los mensajes de sus médicos. Dichos portales envían notificaciones sin que contengan PHI (por ejemplo, «Estimado usuario, tiene un nuevo mensaje de «).

Recuerde que las notificaciones push no son seguras por defecto. Pueden aparecer en la pantalla aunque esté bloqueada. Así que asegúrate de no enviar ningún tipo de información personal a través de las notificaciones push. Lo mismo ocurre con los SMS y cualquier mensaje automático.

Fuente: Bridge Patient Portal

Otra cosa a tener en cuenta es que la FDA puede clasificar algunas apps de mHealth como dispositivos médicos (software que influye en el proceso de toma de decisiones de los profesionales sanitarios).

Así que recuerda comprobar si tu app tiene que cumplir con otras normativas sanitarias antes de empezar a desarrollarla. Puedes consultar este test de la Comisión Federal de Comercio para obtener una respuesta rápida.

Resumen

Ahora ya tienes una lista mínima de características para el software que cumple con la HIPAA.

Solo no garantizan su seguridad. No le protegerán de la suplantación de identidad ni de la ingeniería social.

Pero tener estas características debería convencer a un auditor de que ha hecho lo suficiente para proteger los datos de sus clientes.

Para que las auditorías sean menos dolorosas, documente todos sus esfuerzos de cumplimiento de la HIPAA. Para cada versión de su aplicación, proporcione las especificaciones escritas, los planes para probar su seguridad y sus resultados. Y no olvides comprobar si necesitas cumplir con otras normativas antes de empezar el desarrollo.