Esta entrada forma parte de una serie sobre las sesiones de Health Samurai en HL7 FHIR DevDays 2025. En este artículo, «Control de acceso detallado nativo de FHIR», Rostislav Antonov, ingeniero de software de Health Samurai, muestra cómo las etiquetas de seguridad de FHIR pueden proteger datos clínicos sensibles manteniendo los registros utilizables para los equipos asistenciales.
Lo que aprenderá:
- Por qué diferentes clínicos (por ejemplo, psiquiatras frente a médicos de cabecera) necesitan vistas distintas del mismo historial del paciente.
- Cómo funcionan las etiquetas de seguridad de FHIR tanto a nivel de recurso como a nivel de elemento (campo).
- Cómo el servidor FHIR de Aidbox implementa el control de acceso basado en etiquetas mediante filtrado en base de datos y enmascaramiento en línea.
- Compromisos clave en torno a la privacidad, la seguridad, el rendimiento y la conformidad con FHIR.
Por qué los roles no son suficientes
Los datos sanitarios suelen mezclar información altamente sensible (direcciones, identificadores, notas psiquiátricas) con información clínica rutinaria dentro del mismo recurso. El control de acceso simple basado en roles sobre recursos completos no puede ofrecer a un psiquiatra y a un médico de cabecera vistas adecuadamente diferenciadas sin ocultar demasiado o exponer demasiado. El modelo descrito en la charla presupone que el sistema debe ser capaz de ocultar campos específicos y, al mismo tiempo, devolver el resto del recurso de forma coherente para todos los usuarios y casos de uso.
Las etiquetas de seguridad de FHIR en la práctica
FHIR ofrece etiquetas de seguridad que pueden expresar confidencialidad y finalidad de uso mediante sistemas de códigos de HL7. La charla distingue entre etiquetas jerárquicas (por ejemplo, niveles de confidencialidad en los que «restringido» incluye «normal») y etiquetas planas (como los códigos de finalidad de uso sin jerarquía). Las etiquetas pueden ubicarse en el recurso (meta.security) o en línea a nivel de elemento mediante extensiones, lo que permite patrones como «observaciones exclusivas de psiquiatría» o una dirección particular marcada como sensible a la ubicación mientras una dirección de facturación permanece visible.
Verificación de acceso en dos niveles
El control de acceso combina verificaciones a nivel de recurso y a nivel de elemento. En primer lugar, cada recurso se almacena con etiquetas de seguridad y cada usuario dispone de un conjunto de etiquetas derivadas de su identidad y sus tokens. Las consultas entrantes se reescriben con filtros basados en etiquetas, de modo que la base de datos solo devuelve los recursos cuyas etiquetas coinciden con las del usuario. En segundo lugar, las etiquetas en línea se evalúan a medida que el servidor recorre cada recurso: los campos permitidos se devuelven con normalidad; los campos bloqueados se sustituyen por una extensión data-absent-reason para indicar que el valor está intencionadamente oculto. Esto mantiene las reglas de acceso independientes del tipo de recurso y evita la duplicación de registros.
Ventajas y compromisos
Utilizado de este modo, las etiquetas de seguridad proporcionan un control detallado, reutilizan los estándares existentes de HL7/FHIR y admiten políticas tanto basadas en roles como basadas en atributos. Al mismo tiempo, la charla subraya compromisos importantes: los marcadores de «ausencia» visibles y las propias etiquetas pueden revelar que existen datos ocultos; el enmascaramiento de elementos obligatorios puede romper la conformidad estricta con FHIR; y el recorrido a nivel de elemento añade una sobrecarga de rendimiento mensurable. Por tanto, la política de acceso no puede ser puramente técnica: los despliegues deben decidir cómo equilibrar transparencia, privacidad y corrección.
Consideraciones operativas y demostración
Desde el punto de vista operativo, el modelo depende de una gestión cuidadosa de las etiquetas y de la auditoría. Las etiquetas de usuario provienen de los sistemas de identidad, los clientes deben etiquetar los recursos correctamente y los datos históricos pueden requerir migraciones de reetiquetado. Una etiqueta de «acceso de emergencia» (break-glass) permite anulaciones en situaciones urgentes, pero exige un registro exhaustivo; las implementaciones actuales se centran más en la protección de lectura que en la protección de escritura, como la eliminación de etiquetas. Los escenarios de demostración muestran cómo las etiquetas basadas en JWT dirigen llamadas en Postman donde un usuario ve tanto las observaciones psiquiátricas como las generales y otro solo ve las generales, o donde únicamente ciertas direcciones son visibles, lo que ilustra la divulgación selectiva sin duplicar recursos.
Cómo ayuda esto a los equipos de FHIR
Para las organizaciones que implementan sistemas basados en FHIR, este enfoque muestra cómo las etiquetas de seguridad estándar de FHIR pueden constituir la base de un control de acceso detallado en lugar de un modelo propietario. Demuestra que las etiquetas a nivel de recurso y a nivel de elemento pueden coexistir para admitir políticas expresivas e interoperables, mientras que el análisis explícito de los riesgos de filtración, rendimiento y escritura ayuda a los equipos a diseñar despliegues que sean transparentes sobre sus compromisos, en lugar de tratar las etiquetas como una solución completa.
Recursos
Vea la presentación completa de Rostislav en FHIR DevDays 2025 y la lista de reproducción completa de Health Samurai: Ver el vídeo completo Lista de reproducción completa en YouTube
Conéctese con Rostislav en LinkedIn.
Véase también: RBAC con Keycloak y SMART on FHIR V2.
