Dónde viven realmente los datos de sus pacientes

La pregunta debajo de todas las demás

Pregúntele a un proveedor de software clínico dónde viven sus expedientes. En la mayoría de los casos, la respuesta honesta es: en sus servidores, en su cuenta, bajo su control.

Esa respuesta tiene consecuencias. Su PHI ahora está en un lugar que usted no puede inspeccionar, regido por términos que usted no escribió. Y el proveedor, con los expedientes de miles de consultorios en un solo lugar, se vuelve un blanco permanente y atractivo.

LogBlues lo construimos sobre otra respuesta. Los expedientes se quedan en las máquinas de su consultorio. No hay una copia de sus pacientes en nuestros servidores, porque el uso normal nunca envía una. Eso no es una política que prometamos respetar. Es cómo funciona el software.

El LMLSE: las capas, de afuera hacia adentro

Mantener los datos en local es el cimiento, no todo el edificio. Un archivo local es tan seguro como la máquina que lo tiene. Así que envolvemos al consultorio en el LogBlues Multi-Layered Security Exosystem, capas que cada una asume que la anterior podría fallar. Diez en el diseño completo; seis de ellas trabajando en la versión sólo-local que usted puede descargar hoy.

Capa 1, el dispositivo. Antes de que la aplicación confíe en una máquina, la revisa: cifrado de disco activado, bloqueo de pantalla presente, sin señales de manipulación. Un dispositivo en el que no se confía no llega a ser una excepción silenciosa.
Capa 2, en reposo. Las credenciales y las llaves viven en el almacén seguro del propio sistema operativo, Windows DPAPI y el keystore de Android. Nunca un archivo de llaves casero. Los datos locales están cifrados en reposo.
Capa 3, permisos. El control de acceso por roles se aplica donde se leen los datos, no sólo donde se dibuja un botón. Esconder una opción del menú no es seguridad; es decoración.
Capa 4, la segunda puerta. Las pantallas que contienen PHI real exigen volver a autenticarse. Un código de un solo uso se envía por correo desde un remitente con dominio verificado y firma DKIM, generado desde una fuente criptográficamente segura y con expiración a los diez minutos. El desbloqueo dura sólo esa sesión y termina al cerrar sesión.
Capa 5, el rastro. Las exportaciones, los respaldos, las verificaciones de resultados protegidos y los cambios de política de seguridad se escriben en un registro de seguridad que el usuario que los originó no puede editar calladamente, junto con una exportación local cifrada. Hoy ese registro vive durante la sesión; volverlo duradero, sólo-agregar y completo — que cubra también los inicios de sesión, los accesos a expedientes y los cambios de permisos — es el trabajo que tenemos enfrente en esta capa, y lo mismo la recuperación probada. Un respaldo que nadie ha restaurado es una esperanza, no un plan.
Capa 6, sincronización. Cuando llegue la sincronización en la nube, nunca expondrá una base de datos a internet. La aplicación habla con una API autenticada. El almacenamiento está aislado por consultorio y aplicado a nivel de fila, así que un consultorio no puede leer los datos de otro ni aunque la capa de aplicación esté mal.

Por qué la capa 6 está escrita así

Ese último punto merece un momento, porque es donde la mayoría de los diseños de sincronización se ponen flojos. Es común separar inquilinos en el código de la aplicación y dar el trabajo por terminado. Eso funciona hasta que una consulta se construye mal.

Aplicarlo a nivel de fila significa que el aislamiento vive en la propia capa de almacenamiento. Si la aplicación pide datos que no debería tener, la respuesta sigue siendo no. Estamos diseñando la frontera para que aguante incluso cuando nuestro propio código tenga un mal día.

Sobre el cumplimiento, dicho con claridad

LogBlues está preparado para HIPAA desde el primer día. Cifrado en reposo, controles de acceso aplicados en la capa de datos, un registro de auditoría, reautenticación para PHI, recuperación probada. Estas son las salvaguardas técnicas que contempla la norma, y vienen integradas en lugar de atornilladas encima.

Aquí va la parte honesta. Estar en regla es una propiedad de un consultorio y de sus acuerdos, no del software por sí solo. Depende de sus políticas, su capacitación, sus business associate agreements, y de cómo se comporta realmente su personal un jueves ajetreado. Cualquier proveedor que le diga que su producto lo pone en regla le está vendiendo una sensación.

Lo que el software sí puede hacer es volver lo correcto la opción por defecto y lo incorrecto difícil. Mantener los datos donde usted puede verlos. Cifrarlos. Revisar la máquina. Poner puerta a las pantallas sensibles. Registrar cada consulta. Y luego, cuando llegue la sincronización, negarse a aflojar nada de eso por comodidad.

Usted no debería tener que confiarnos a sus pacientes para poder usar nuestro software. Ese es el punto de construirlo así.