Respuesta corta: la seguridad en una aplicación de salud responde a cuatro preguntas, en orden. ¿Quién es? Identidad: un usuario verificado (paciente, médico, sistema) a través de OpenID Connect y, para los médicos, la identidad profesional nacional; el nivel de verificación importa más que la fortaleza de la contraseña. ¿Qué pueden hacer? Autorización: tokens OAuth 2.0 (evolucionando a 2.1) con alcances en sintaxis SMART on FHIR, derivados del consentimiento del paciente para un propósito y una duración, aplicados en la capa de datos. ¿Qué hicieron? Rendición de cuentas: un registro de acceso que el paciente puede leer y un rastro de AuditEvent de FHIR para la organización. ¿Están los datos seguros en reposo, en tránsito y en copias de seguridad? Protección: cifrado, gestión de claves, segregación, restauraciones probadas. A su alrededor: la base de ISO 27001 y 27799, NIS2 y la Regla de Seguridad de HIPAA, y las amenazas específicas de los datos de salud (navegación interna, errores de archivo, ransomware).
El mapa
La seguridad y la identidad en una aplicación de salud forman siete capas: identidad a través de OpenID Connect e identificaciones nacionales o profesionales, autorización a través de OAuth 2.0 y ámbitos SMART on FHIR, consentimiento como fuente de cada concesión, rendición de cuentas a través de registros de acceso y FHIR AuditEvent, protección a través de cifrado y copias de seguridad, una base de ISO 27001, ISO 27799, NIS2 y HIPAA, y uso compartido iniciado por el paciente.
| Capa | Estándar o práctica | Lo que te proporciona | Página |
|---|---|---|---|
| Identidad | OpenID Connect; identidades nacionales (eIDAS, NHS login, GesundheitsID); identidades profesionales (eHBA, CPS, UZI) | Un sujeto verificado con un nivel de garantía | SMART App Launch explicado |
| Autorización | OAuth 2.0 y 2.1 (PKCE obligatorio, sin concesiones implícitas o de contraseña); alcances SMART on FHIR (patient/Observation.rs); servicios backend con autenticación de cliente asimétrica | Tokens vinculados a un usuario, un contexto de paciente y un alcance | SMART App Launch explicado, SMART on FHIR backend |
| Consentimiento | FHIR Consent; concesiones basadas en propósito y tiempo; revocación; "break-the-glass" con justificación y alerta | El paciente como origen de cada autorización | Plataforma de consentimiento del paciente, Solicitudes de acceso de clínica |
| Rendición de cuentas | Registros de acceso por registro visibles para el paciente; FHIR AuditEvent; almacenamiento a prueba de manipulaciones; retención | Quién vio qué, cuándo, por qué | ¿Quién vio mi historial médico? |
| Protección | TLS 1.2+, cifrado en reposo con claves gestionadas, cifrado a nivel de campo para identificadores, entornos segregados, copias de seguridad con restauración probada | Confidencialidad y disponibilidad | ISO 27001 vs ISO 27799 |
| Base | ISMS ISO 27001, controles de salud 27799, medidas NIS2, Regla de Seguridad HIPAA, esquemas nacionales (HDS, DSPT, C5) | Lo que esperan hospitales, auditores y reguladores | NIS2 para hospitales y proveedores, HIPAA vs GDPR |
| Compartir | SMART Health Links y Cards; credenciales verificables | Compartir iniciado por el paciente con un enlace o QR, revocable | SMART Health Links explicado |
Identidad: garantía sobre contraseñas
La identidad en una aplicación de salud depende de la garantía en lugar de la fortaleza de la contraseña: los niveles de garantía de identidad como NIST IAL, eIDAS sustancial y alto, o NHS login P9 describen cuán fuertemente se verificó a una persona al registrarse, mientras que la autenticación multifactor y las passkeys describen cada inicio de sesión. Los médicos se identifican a través de identidades profesionales que se revocan cuando se van.
Una aplicación para pacientes que muestra un registro completo debe saber que está hablando con ese paciente. Los niveles de garantía de identidad (IAL de NIST, sustancial y alto de eIDAS, NHS login P9) describen cuán fuertemente se verificó la identidad en el registro; la fortaleza de la autenticación (multifactor, passkeys) describe cada inicio de sesión. Los hospitales y los sistemas nacionales requieren cada vez más identidades verificadas de esquemas reconocidos en lugar de registros autoafirmados, y la Cartera de Identidad Digital de la UE se convertirá en un medio aceptado. Para los médicos, la identidad profesional (y su revocación cuando alguien se va) es el sistema de registro de quién puede actuar como médico en absoluto.
Autorización: el consentimiento se convierte en alcances
La autorización en un registro controlado por el paciente traduce el consentimiento del paciente, como permitir que una clínica lea resultados de laboratorio y condiciones durante 90 días, en ámbitos OAuth y contexto del paciente en el token, en sintaxis SMART on FHIR como patient/Observation.rs, aplicado en la capa de datos en cada solicitud y revocado cuando el paciente lo retira. "Break-the-glass" es una vía separada y auditada.
En un registro controlado por el paciente, el consentimiento del paciente es la política: esta clínica puede leer mis resultados de laboratorio y condiciones durante 90 días. El sistema lo traduce en alcances OAuth y contexto (qué paciente, qué recursos, qué operaciones) en el token que recibe el sistema de la clínica, los aplica en cada solicitud en la capa de datos y los revoca cuando el paciente lo retira. La sintaxis de alcance de SMART on FHIR (patient/Observation.rs, patient/Condition.rs) es la lengua franca para esto; existen alcances granulares (por categoría o código) en SMART v2 para un control más fino. Break-the-glass (acceso de emergencia sin consentimiento) es una ruta separada y auditada con justificación obligatoria y una alerta al paciente, nunca un valor predeterminado. Ver Plataforma de consentimiento del paciente.
Rendición de cuentas: el registro que lee el paciente
La rendición de cuentas en una aplicación de salud significa que cada acceso a un registro, por quién, cuándo, qué y bajo qué consentimiento, se escribe en un registro inmutable que el paciente puede leer en su aplicación y en un rastro de auditoría organizacional en FHIR AuditEvent. ISO 27799 trata esto como obligatorio, y un registro visible es el disuasorio más fuerte contra la navegación interna.
Cada acceso a un registro, por quién, cuándo, qué, bajo qué consentimiento, se escribe en un registro de solo adición que el paciente puede leer en su aplicación, y en un rastro de auditoría organizacional (FHIR AuditEvent) para los equipos de seguridad. ISO 27799 lo considera obligatorio para la información de salud; el principio de transparencia del GDPR y los derechos del paciente del EHDS apuntan en la misma dirección; el mayor disuasivo en el mundo real para la navegación interna es un registro visible. Ver ¿Quién vio mi historial médico?.
Protección: la base de ingeniería
La base de ingeniería para proteger los datos de salud es TLS en todas partes, cifrado en reposo con claves administradas y rotadas, cifrado o tokenización separada para identificadores directos, entornos segregados con datos sintéticos fuera de producción, acceso de mínimo privilegio con autenticación multifactor para administradores, gestión de secretos y vulnerabilidades, copias de seguridad cifradas probadas mediante restauración contra ransomware, y respuesta a incidentes dentro de los plazos de GDPR y NIS2.
TLS en todas partes, con cifrados modernos y fijación de certificados en aplicaciones cuando sea apropiado; cifrado en reposo con claves en un servicio de claves gestionado y rotación; cifrado o tokenización separada para identificadores directos; segregación de producción de desarrollo, con datos sintéticos fuera de producción; acceso de mínimo privilegio para el personal, sin cuentas compartidas, multifactor para todo acceso administrativo; gestión de secretos; gestión de dependencias y vulnerabilidades con divulgación; copias de seguridad cifradas, probadas mediante restauración y protegidas contra el ransomware que ha afectado repetidamente a hospitales y laboratorios (WannaCry en 2017, el hospital de Düsseldorf en 2020, Change Healthcare y Synnovis en 2024). Respuesta a incidentes con los relojes de 72 horas del GDPR y 24 horas de NIS2 en un solo manual de operaciones.
Amenazas específicas de los datos de salud
Las amenazas específicas de los datos de salud son la navegación interna de registros de conocidos, la clasificación errónea entre pacientes, el uso compartido excesivamente amplio concedido durante demasiado tiempo, los SDK de publicidad dentro de las aplicaciones que manejan datos de salud, la inyección de documentos en funciones de IA y la retención prolongada durante décadas durante las cuales las claves, los formatos y las reglas de acceso deben sobrevivir al personal y a los proveedores.
- Navegación interna de registros de conocidos o figuras públicas: acceso basado en relaciones y registros visibles.
- Errores de archivo entre pacientes: reconciliación de identidad y procedencia, no solo control de acceso.
- Compartir excesivamente amplio: una clínica a la que se le concedió "todo" durante un año; alcances y duraciones con valores predeterminados sensatos.
- Aplicaciones con SDK de publicidad: sin rastreadores de terceros en nada que maneje datos de salud.
- Inyección a través de documentos en funciones de IA: el contenido son datos, nunca instrucciones (RAG en historiales médicos).
- Retención prolongada: los registros viven durante décadas; las claves, los formatos y las reglas de acceso deben sobrevivir al personal y a los proveedores.
En Anpheros
Anpheros aplica el mapa de seguridad a sí mismo con OAuth 2.0 con PKCE para aplicaciones y autenticación de cliente asimétrica para backends, consentimiento por propósito y duración como fuente de acceso de cada clínica, un registro de acceso por registro en la aplicación de la persona, cifrado en reposo y en tránsito, alojamiento en la UE, sin SDK de publicidad y un ISMS según ISO 27001 y 27799.
Anpheros se aplica este mapa a sí mismo: OAuth 2.0 con PKCE para aplicaciones y autenticación de cliente asimétrica para backends; consentimiento por propósito y duración como origen del acceso de cada clínica, con revocación y sin "break-the-glass" silencioso; un registro de acceso por registro en la aplicación de la persona; cifrado en reposo y en tránsito, alojamiento en la UE, sin SDK de publicidad; un ISMS según ISO 27001 con los controles de salud 27799. El sitio para desarrolladores documenta autenticación, consentimiento y seguridad.
Páginas relacionadas
- SMART App Launch explicado
- Plataforma de consentimiento del paciente
- ¿Quién vio mi historial médico?
- SMART Health Links explicado
- ISO 27001 vs ISO 27799
- NIS2 para hospitales y proveedores de tecnología sanitaria
- Seguridad de la plataforma (sitio para desarrolladores)
- Autenticación (sitio para desarrolladores)
Fuentes
- HL7 SMART App Launch
- IETF: OAuth 2.1 (borrador)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Digital Identity Guidelines
- ISO 27799:2016
- ENISA: Guías de adquisición de ciberseguridad en hospitales
Preguntas frecuentes
¿Es OAuth 2.1 diferente de 2.0?
OAuth 2.1 consolida 2.0 con sus mejores prácticas de seguridad: PKCE es obligatorio para todos los clientes, se eliminan las concesiones implícitas y de contraseña, las URI de redirección deben coincidir exactamente y los tokens de actualización para clientes públicos deben estar vinculados o rotados. SMART on FHIR v2 ya requiere la mayoría de esto.
¿Qué es "break-the-glass"?
Acceso de emergencia a un registro sin el consentimiento previo del paciente, por parte de un médico que presenta una justificación. Debe ser raro, registrado, revisado y reportado al paciente; nunca es la ruta de acceso predeterminada.
¿Por qué los pacientes deberían ver el registro de acceso?
Porque es el disuasivo más fuerte contra el acceso inapropiado y la expresión más clara de control: la persona ve qué clínica leyó qué y cuándo, y puede revocarlo. ISO 27799 y el EHDS apuntan en la misma dirección.
¿Necesito un sistema de auditoría separado?
Necesita un rastro de auditoría de solo adición (FHIR AuditEvent o equivalente) que la aplicación no pueda alterar, retenido según la política, y una vista orientada al paciente derivada de él. Si es un sistema separado o un almacenamiento protegido dentro de la plataforma es una elección de implementación.
Pruébalo gratis en el sandbox
Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.
Gratis · 30 pacientes sintéticos · sin tarjeta
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →