Historia clínica en la nube: controles que sí importan

Contratar un proveedor de nube grande no traslada la responsabilidad sobre la historia clínica. El proveedor asegura la infraestructura; la clínica sigue respondiendo del cifrado que activa, del control de acceso por rol, del registro de accesos y de la política de retención y borrado.

Es la confusión más cara del sector salud digital: interpretar el nombre del proveedor como una capa de cumplimiento. Un contrato con un hiperescalar reconocido reduce ciertas clases de riesgo y no toca otras en absoluto. Este texto separa exactamente cuáles son unas y cuáles otras.

¿Qué aporta realmente el proveedor de nube?

Lo que el proveedor sostiene es la seguridad de la nube. Es mucho, y es real:

• Seguridad física de los centros de datos y control de acceso a las salas.
• Redundancia eléctrica, de refrigeración y de red.
• Parcheado del hipervisor y de la infraestructura subyacente.
• Aislamiento entre inquilinos y segregación de red base.
• Disponibilidad de servicios de cifrado, gestión de claves, registro y copia.
• Certificaciones y auditorías de tercero sobre esa capa, cuyo alcance figura en el informe correspondiente.

Nada de eso incluye decidir quién puede ver la historia de un paciente concreto, cuánto tiempo se conserva, si la exportación masiva está permitida o si el usuario de recepción tiene el mismo perfil que el facultativo. Esas decisiones son de la clínica y ningún contrato las absorbe.

Las Guidelines on Security and Privacy in Public Cloud Computing (NIST SP 800-144) plantean esta división desde hace más de una década, y sigue siendo el punto de partida conceptual: la externalización desplaza el control, no la responsabilidad.

¿Dónde está exactamente la frontera de responsabilidad?

La frontera se mueve según el modelo de servicio. Esta tabla es la referencia práctica.

Capa	Infraestructura como servicio	Plataforma como servicio	Software como servicio
Instalaciones físicas y hardware	Proveedor	Proveedor	Proveedor
Red base e hipervisor	Proveedor	Proveedor	Proveedor
Sistema operativo y parcheado	Cliente	Proveedor	Proveedor
Configuración del servicio	Cliente	Cliente	Cliente, en lo que el producto permita
Identidades, roles y permisos	Cliente	Cliente	Cliente
Cifrado a nivel de aplicación y claves	Cliente	Cliente	Compartido, según producto
Datos, retención y borrado	Cliente	Cliente	Cliente
Registro de acceso al dato clínico	Cliente	Cliente	Cliente, sobre lo que el producto registre

Dos lecturas importan aquí.

La columna de software como servicio no es la columna vacía. Contratar un sistema de gestión clínica en modalidad SaaS elimina el parcheado, no la responsabilidad sobre quién accede a qué. Y añade una tarea nueva: verificar qué registra el producto, porque no se puede auditar lo que el proveedor no expone.

La configuración es del cliente en los tres modelos. La inmensa mayoría de las exposiciones de datos clínicos en la nube que se hacen públicas tienen la misma raíz: un almacenamiento con permisos amplios, una copia de seguridad accesible, una integración con una credencial de más privilegio del necesario. Ninguna es un fallo del proveedor.

¿Qué figura jurídica adopta el proveedor?

Antes de hablar de controles hay que fijar el marco, porque determina qué se puede exigir por contrato.

• En el ámbito del RGPD, el proveedor de nube actúa normalmente como encargado del tratamiento y la clínica como responsable. El artículo 28 del Reglamento (UE) 2016/679 obliga a formalizar un contrato con contenido mínimo: objeto, duración, instrucciones documentadas, confidencialidad, medidas de seguridad, subencargados, asistencia al responsable y destino de los datos al terminar.
• En el ámbito estadounidense, cuando se tratan datos de salud protegidos, el proveedor suele encajar como business associate y opera bajo el acuerdo correspondiente. La guía NIST SP 800-66 Rev. 2, de febrero de 2024, es el recurso de referencia para traducir las salvaguardas exigidas por la HIPAA Security Rule a controles concretos.

Si la clínica opera en varias jurisdicciones —consulta en línea transfronteriza, pacientes de países distintos, filial en otro Estado— pueden convivir varios regímenes sobre la misma historia clínica. Ese mapeo es la primera entrega de servicios: compliance, y su omisión es la razón más común de que un contrato de nube perfectamente firmado no cubra lo que la organización cree que cubre.

¿Qué cifrado protege de qué?

"Los datos están cifrados" no es una afirmación evaluable. Estas cuatro sí lo son.

Tipo de cifrado	Protege frente a	No protege frente a
En tránsito (TLS)	Interceptación en la red entre cliente y servicio	Cualquier acceso legítimo en los extremos
En reposo, gestionado por el proveedor	Sustracción física del soporte, retirada de discos	Credencial robada con permisos válidos, error de configuración
En reposo, con clave gestionada por el cliente	Lo anterior, más acceso administrativo del proveedor sin la clave	Compromiso del sistema de gestión de claves del cliente
A nivel de aplicación o de campo	Lectura del dato por cualquier capa por debajo de la aplicación, incluida la base de datos	Un usuario de la aplicación con permiso para ver ese campo

La conclusión operativa es incómoda y conviene decirla claro: el cifrado en reposo estándar no protege frente al escenario más probable, que es un acceso con credenciales válidas robadas. Por eso el control de acceso y la autenticación pesan más que el algoritmo. Sobre este punto concreto escribimos en MFA resistente al phishing: por qué el SMS ya no basta.

¿Cómo se diseña el control de acceso por rol en una clínica?

El modelo de rol útil no se copia de una plantilla: se deriva del flujo asistencial real. Cuatro reglas lo resumen.

1. Mínimo privilegio por función, no por jerarquía. El director médico no necesita acceso a todas las historias por ser director; lo necesita si asiste a ese paciente.
2. Relación asistencial como condición de acceso. El acceso a una historia se vincula a una cita, un episodio o una derivación. Sin vínculo, el sistema pide justificación explícita y la registra.
3. Ruptura de cristal documentada. Debe existir una vía de acceso urgente sin relación previa —una urgencia real no espera a un flujo de autorización— pero cada uso genera un registro destacado y una revisión posterior obligatoria.
4. Perfiles diferenciados para lo que no es asistencia. Recepción, facturación, investigación y soporte técnico necesitan subconjuntos distintos, y casi ninguno necesita el diagnóstico completo.

Añadido a lo anterior, tres controles que suelen faltar: caducidad automática de cuentas de personal temporal, revisión periódica de permisos con firma del responsable de servicio, y separación estricta entre entornos de producción y de pruebas, con datos de prueba sintéticos o seudonimizados. Copiar la base de producción a un entorno de pruebas es una de las formas más habituales de crear una fuga sin que nadie ataque nada.

¿Qué debe registrar el sistema y cuánto tiempo?

El registro de accesos es lo que convierte una sospecha en un hecho. Un registro clínico útil contiene, como mínimo:

• Identidad del usuario y del rol con el que actuó.
• Identificador del paciente o del episodio consultado.
• Acción realizada: consulta, modificación, exportación, impresión.
• Marca temporal fiable y origen de la conexión.
• Motivo o justificación cuando el acceso fue por vía de excepción.

Y tres propiedades que se descuidan: que el registro sea inalterable por quien accede al dato, que se conserve el tiempo suficiente para cubrir el horizonte de reclamación aplicable, y que exista alerta activa sobre patrones anómalos —exportaciones masivas, consultas fuera de horario, acceso repetido a pacientes sin relación asistencial—. Un registro que solo se lee cuando ya hay un problema es una herramienta forense; el objetivo es que también sea preventiva.

La retención es la otra cara. Los plazos de conservación de la historia clínica los fija la normativa sanitaria de cada jurisdicción y no coinciden con los plazos de minimización de otros datos: el correo de contacto de un paciente puede tener que borrarse mucho antes que su historia. Una política de retención que trata todo el dato clínico como un bloque único falla siempre en una de las dos direcciones.

¿Cómo se comprueba que el proveedor cumple lo que dice?

Con documentos, no con logotipos.

• Informe de auditoría de tercero y su alcance. Un informe existe o no existe, y cubre unos servicios y unas regiones concretas. Si el servicio que usa la clínica no está en el alcance, el informe no aplica a ese servicio.
• Lista de subencargados y mecanismo de notificación de cambios. Si el proveedor puede subcontratar sin avisar, la cadena de tratamiento es desconocida.
• Ubicación de almacenamiento y de procesamiento, incluidas copias y soporte técnico. El dato en reposo en una región y el soporte accediendo desde otra son dos cuestiones distintas.
• Compromiso de asistencia en brechas, con plazo. Sin plazo contractual, el plazo regulatorio de la clínica depende de la buena voluntad del proveedor. Este punto lo desarrollamos en Padrón de afiliados filtrado: contención y aviso.
• Procedimiento de salida y devolución o borrado certificado. Antes de entrar conviene saber cómo se sale y en qué formato.

Nosotros aplicamos ese mismo criterio a nuestra propia casa: el estado real de cada marco, sin etiquetas que insinúen certificaciones inexistentes, está publicado en /trust.

Qué hacer ahora

1. Dibuja la tabla de responsabilidad compartida de tu contrato real, servicio por servicio. Si nadie de la organización puede rellenarla, ese es el primer hallazgo.
2. Comprueba quién custodia las claves de cifrado y qué protege exactamente ese cifrado. Escríbelo en una frase que un no técnico entienda.
3. Exporta hoy el registro de accesos de la última semana y busca tres cosas: exportaciones masivas, accesos fuera de horario y accesos sin relación asistencial.
4. Revisa si algún entorno de pruebas contiene datos clínicos reales. Si los contiene, ese es el trabajo de esta semana.
5. Verifica los plazos de retención por tipo de dato, no por sistema.

Si quieres una revisión de la configuración, el reparto de responsabilidad y el circuito de acceso a la historia clínica —con la parte técnica y la jurídica en el mismo informe—, escríbenos desde /contacto. El enfoque completo del sector está en sectores: salud digital y wellness y el alcance técnico en servicios: protección.