🔥 Etiquetas de seguridad FHIR: Control de acceso detallado

El problema fundamental

Los registros sanitarios no son un archivo monolítico único; son un mosaico de resultados de laboratorio, identificadores de facturación, notas de salud mental, datos demográficos y mucho más. El reto consiste en proporcionar a los profesionales sanitarios únicamente los datos que necesitan para trabajar con eficacia. El objetivo es evitar exponer más información de la necesaria. Este principio de «necesidad de saber» es precisamente lo que las etiquetas de seguridad están diseñadas para aplicar.

Veamos un ejemplo concreto. Un psiquiatra que trabaja con un paciente debe tener acceso a información de salud mental muy sensible junto con datos generales relacionados con su atención médica. Una enfermera que trabaja con el psiquiatra también debería tener acceso a las notas de salud mental. Sin embargo, ¿desearía usted que otras enfermeras leyeran sus notas de salud mental? Probablemente no. Asimismo, un médico de atención primaria puede necesitar ver las constantes vitales de un paciente, pero no debería tener acceso a la información de salud mental por diversas razones. Esta lista puede ser interminable y siempre depende de las políticas específicas de cada institución.

Tabla de permisos por rol

Rol	Necesita ver	NO debe ver
Psiquiatra	Frecuencia cardíaca, Salud mental	–
Enfermera	Frecuencia cardíaca, ¿Salud mental?	Salud mental (depende)
Médico de atención primaria	Frecuencia cardíaca	Salud mental
Personal de facturación médica	Dirección de facturación, NSS	Domicilio
Investigador clínico	Constantes vitales seudonimizadas	Nombres, NSS

Perspectiva del implementador FHIR

Las observaciones desempeñan un papel fundamental en la atención sanitaria y, en FHIR, el recurso Observation es intencionadamente amplio. Puede representar desde una lectura de frecuencia cardíaca hasta una medición de presión arterial o una evaluación de depresión — todos ellos se engloban bajo el mismo tipo de recurso.

Pero no todo el mundo debería ver los mismos datos. Cuando su aplicación envía una solicitud GET para obtener observaciones, la respuesta del servidor FHIR debe depender de quién utiliza la aplicación. Por ejemplo, los médicos de atención primaria no deberían ver las evaluaciones de depresión, mientras que los psiquiatras dependen de ellas. Se trata de la misma solicitud y el mismo Bundle — pero distintos usuarios deberían obtener resultados diferentes.

Tomemos otro recurso FHIR: el Patient. Contiene mucha información y, con frecuencia, los pacientes tienen diferentes direcciones para su domicilio, facturación o correspondencia. Es posible que no deseen compartir su domicilio con todo el mundo. Lo mismo ocurre con su número de seguridad social — el personal de facturación puede necesitarlo, pero el resto del personal de la clínica no.

Todos estos datos residen dentro del mismo recurso Patient, por lo que necesitamos una manera de ocultar determinados campos manteniendo el recurso accesible. En otras palabras, el control de acceso debe ser configurable no solo a nivel de recurso, sino también a nivel de elementos o propiedades individuales.

¿Es posible alcanzar tal nivel de granularidad en el control de acceso?

La respuesta de FHIR son las Security Labels — un concepto pequeño pero poderoso que se adjunta a los recursos.

Etiquetas de seguridad FHIR

Imagine esta imagen como nuestra base de datos FHIR. Podemos adjuntar etiquetas o marcas directamente dentro de la base de datos a cada recurso, o incluso a propiedades específicas dentro de un recurso. Estas etiquetas indican al servidor FHIR quién tiene permiso para ver qué información.

Las etiquetas de seguridad FHIR funcionan en dos niveles de granularidad distintos:

1. Etiquetas a nivel de recurso: son el enfoque más sencillo. Estas etiquetas se adjuntan a un recurso FHIR completo mediante la propiedad meta.security. Pueden entenderse como marcas que indican «este registro completo de Patient es confidencial» o «esta Observation completa contiene información sensible». Dado que meta.security es un array, es posible adjuntar múltiples etiquetas a un único recurso — por ejemplo, marcarlo como «confidencial» y «relacionado con salud mental» al mismo tiempo.

{
  "meta": {
    "security": [
      {
        "code": "R",
        "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality"
      },
      {
        "code": "PSY",
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
      }
    ]
  },
  "resourceType": "Patient",
  ... rest of the resource
}

2. Etiquetas a nivel de propiedad (también denominadas etiquetas en línea) proporcionan un control mucho más preciso. Permiten proteger propiedades específicas dentro de un recurso dejando accesibles las demás. Para usar etiquetas a nivel de propiedad, primero debe añadir el indicador especial PROCESSINLINELABEL a la propiedad meta.security del recurso. A continuación, puede adjuntar etiquetas de seguridad a propiedades individuales mediante extensiones FHIR. Por ejemplo, podría proteger únicamente el domicilio en un recurso Patient manteniendo visible la dirección de facturación.

{
  "meta": {
    "security": [
      {
        "code": "PROCESSINLINELABEL",
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
      }
    ]
  },
  "resourceType": "Patient",
  "address": [
    {
      "use": "home",
      "city": "Metropolis",
      "line": [
        "123 Confidential Ave"
      ],
      "state": "MA",
      "country": "US",
      "extension": [
        {
          "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
          "valueCoding": {
            "code": "LOCIS",
            "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
          }
        }
      ]
    },
    {
      "use": "billing",
      "city": "Metropolis",
      "line": [
        "123 Non-Confidential Ave"
      ],
      "state": "MA",
      "country": "US"
    }
  ]
  ... rest of the resource
}

Anatomía de una etiqueta de seguridad FHIR

Las etiquetas de seguridad FHIR utilizan sistemas de códigos HL7 estandarizados.

El sistema v3 Confidentiality funciona de forma jerárquica, similar a los niveles de habilitación de seguridad. Si un usuario dispone de acceso «Restricted», automáticamente puede ver los datos con niveles inferiores, como «Normal» y «Low».

Los sistemas ActCode y Purpose of Use son planos — o se dispone del código exacto correspondiente o no se dispone de él. Tener acceso a un código no otorga acceso a los demás.

Conocer el vocabulario es solo la mitad de la historia. Veamos cómo utiliza realmente un servidor FHIR estas etiquetas en el momento de procesar una solicitud — desde el etiquetado de los datos hasta el enmascaramiento de propiedades.

Cómo funcionan las etiquetas de seguridad

El flujo de trabajo de las etiquetas de seguridad sigue tres pasos principales:

1. Etiquete sus datos y usuarios. Cada recurso FHIR recibe etiquetas de seguridad adjuntas, y a los usuarios se les asignan niveles de habilitación que especifican a qué información pueden acceder.

2. Compare los permisos del usuario con las etiquetas del recurso. Cuando un usuario solicita datos, el motor de control de acceso compara la habilitación del usuario con las etiquetas de seguridad del recurso aplicando las reglas de coincidencia de etiquetas configuradas (por ejemplo, niveles de dominancia, requisitos de etiquetas «todas» frente a «alguna», restricciones de propósito). El acceso se concede únicamente si dichas reglas se satisfacen a nivel de recurso.

3. Compruebe las restricciones a nivel de propiedad. Si un recurso contiene el indicador PROCESSINLINELABEL, el servidor examina las propiedades individuales dentro de ese recurso. Las propiedades a las que el usuario no puede acceder se enmascaran mediante la extensión estándar data-absent-reason de FHIR con el valor "masked".

Detalles de implementación

A continuación se describe cómo hemos implementado este flujo de trabajo en nuestro servidor FHIR, Aidbox:

1. Obtención de los permisos del usuario. Cuando llega una solicitud, Aidbox determina primero el nivel de acceso del usuario comprobando sus etiquetas de seguridad en dos lugares: la reclamación "scope" en el token de acceso JWT y la propiedad opcional User.securityLabel en el registro del usuario.

2. Expansión de etiquetas jerárquicas. Para los códigos de confidencialidad, el sistema expande automáticamente la jerarquía. Si un usuario tiene acceso «Restricted», Aidbox añade todas las etiquetas de nivel inferior («Normal», «Low», «Unrestricted») a sus permisos.

3. Aplicación del filtrado a nivel de recurso. Internamente, Aidbox inyecta las etiquetas de seguridad del usuario en el parámetro de búsqueda _security de FHIR para filtrar los recursos. Por ejemplo, si un usuario tiene habilitación de confidencialidad «R» (Restricted) y la etiqueta «PSY» (información sobre trastornos psiquiátricos), una solicitud simple como GET /fhir/Observation se transforma en:

GET 
/fhir/Observation?_security=http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|N,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|L,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|U,
http://terminology.hl7.org/CodeSystem/v3-ActCode|PSY

Dado que Aidbox utiliza PostgreSQL como base de datos, esta solicitud FHIR se transforma en una consulta SQL. En este punto, Aidbox aplica el control de acceso a nivel de recurso, ya que la consulta SQL solo devolverá recursos con etiquetas de seguridad coincidentes. Los recursos sin etiquetas o con etiquetas no coincidentes quedan excluidos automáticamente de los resultados.

4. Gestión del acceso a nivel de propiedad. Para los recursos con el indicador PROCESSINLINELABEL, Aidbox examina cada propiedad con etiquetas de seguridad en línea. Las propiedades accesibles se devuelven tal cual, mientras que las propiedades restringidas se enmascaran con la extensión data-absent-reason.

Ventajas

A continuación se resumen las ventajas de las etiquetas de seguridad:

1. Interoperabilidad. Las etiquetas de seguridad utilizan sistemas de códigos HL7 nativos.

2. Granularidad a nivel de recurso. Es posible etiquetar recursos individuales con múltiples etiquetas en lugar de construir el control de acceso basándose en tipos de recursos. Esto permite consultar todas las Observations de forma segura sin preocuparse por exponer datos sensibles de salud mental a usuarios que no deberían verlos.

3. Granularidad a nivel de propiedad. Las etiquetas de seguridad en línea permiten enmascarar una única propiedad de un recurso mientras el resto del recurso permanece accesible.

Inconvenientes

Las etiquetas de seguridad conllevan importantes inconvenientes que deben tenerse en cuenta:

1. La visibilidad de las etiquetas puede filtrar información

Cuando los usuarios ven extensiones data-absent-reason junto a las etiquetas de seguridad, un usuario malintencionado puede descubrir de inmediato qué nivel de acceso se necesita para ver los datos ocultos. Esto podría dar lugar a un problema de control de acceso. Aidbox ofrece un indicador de eliminación de etiquetas para suprimir las etiquetas de seguridad de la respuesta.

2. Seguridad médica frente a fuga de datos

La divulgación de la ausencia de datos puede constituir en sí misma una fuga de información. Al enmascarar propiedades sensibles mediante data-absent-reason="masked", se está indicando al usuario: «hay algo aquí que usted no puede ver». En el caso de información estigmatizante, como la salud mental o el abuso de sustancias, incluso saber que existen datos puede resultar problemático.

Podría argumentarse que simplemente se prescinda del enmascaramiento y se elimine la propiedad del recurso por completo, como si no existiera. Sin embargo, esto introduce otro problema — si las denegaciones de acceso a datos no se revelan, podrían interpretarse como que los datos no existen, lo que podría conducir a decisiones médicas erróneas.

No existe una solución sencilla para esto. Debe ser una decisión cuidadosa para cada caso concreto.

3. Privacidad frente a conformidad

La especificación FHIR exige que ciertas propiedades de los recursos estén presentes, pero los requisitos de privacidad pueden obligar a enmascararlas. ¿Qué ocurre cuando modificamos una propiedad requerida de FHIR? Significa que devolveremos un recurso no conforme en la respuesta.

Por ejemplo, status es una propiedad obligatoria en Observation. Pero si desea enmascararla, devolverá un recurso que no es válido.

{
  "id": "bp-001",
  "resourceType": "Observation",
  "meta": {
    "security": [ ...labels... ]
  },
  "_status": {
    "extension": [
      {
        "url": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
        "valueCode": "masked"
      }
    ]
  },
  "code": {
    "coding": [
      {
        "extension": [
          {
            "url": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
            "valueCode": "masked"
          }
        ]
      }
    ]
  }
}

Aunque «la conformidad por el bien de la conformidad» podría ser un compromiso aceptable, se convierte en un problema real cuando las aplicaciones cliente dependen de que esas propiedades obligatorias estén presentes. En definitiva, «es privacidad frente a conformidad, y a veces la privacidad debe prevalecer».

4. Sobrecarga de rendimiento

Como habrá podido observar, la aplicación de etiquetas de seguridad añade una sobrecarga de procesamiento en varios puntos.

Realizamos pruebas de rendimiento y comparamos tres configuraciones de Aidbox: Sin control de acceso basado en etiquetas

Con etiquetas a nivel de recurso
Con etiquetas en línea

Medimos las operaciones de lectura FHIR, realizando solicitudes GET /fhir/Patient/id. Los resultados mostraron una ralentización del 6,2 % para las etiquetas a nivel de recurso y del 7,4 % para las etiquetas a nivel de propiedad. Por lo tanto, si su aplicación no requiere cada milisegundo de rendimiento, este no es un problema importante.

Operaciones de creación y actualización

Nuestra implementación de etiquetas de seguridad FHIR cubre actualmente solo las operaciones de lectura y búsqueda. Las operaciones de creación y actualización requieren un tratamiento adicional.

El problema

Considere este escenario: un cliente solicita un recurso Patient en el que el domicilio está enmascarado debido a permisos insuficientes. El cliente ve la dirección de facturación y otras propiedades, y a continuación desea actualizar el número de teléfono del paciente. ¿Cómo debe gestionar el servidor FHIR esta actualización sin perder los datos del domicilio oculto?

Enfoque recomendado

Evite por completo las operaciones PUT — PUT reemplaza el recurso completo, lo que haría perder las propiedades enmascaradas que el cliente no podía ver.
Use operaciones PATCH en su lugar — PATCH permite actualizaciones selectivas de propiedades específicas sin afectar al recurso completo.
Validación en el lado del cliente — Implemente lógica para permitir únicamente el parcheo de propiedades que no estaban enmascaradas en la respuesta original.

Etiquetas a nivel de recurso frente a etiquetas a nivel de propiedad

Etiquetas a nivel de recurso (en meta.security): FHIR recomienda preservar las etiquetas en meta durante la operación de creación, aunque igualmente debe tenerse precaución con las actualizaciones.
Etiquetas a nivel de propiedad (extensiones en línea): son más complejas, ya que existen dentro de los propios datos del recurso.

Este sigue siendo un área en evolución en la que los servidores FHIR necesitan lógica personalizada para gestionar las actualizaciones de forma segura preservando los límites de seguridad.

No existe una solución universal

La principal conclusión de este artículo es que las etiquetas son una herramienta potente, pero conllevan numerosos inconvenientes que deben considerarse detenidamente.

Demo en Postman

Pruebe la implementación de etiquetas de seguridad FHIR de Aidbox en Postman. Le rogamos que lea la descripción de la colección de Postman antes de ejecutar las solicitudes.

Puede utilizar la colección de Postman proporcionada para explorar distintos escenarios que impliquen control de acceso detallado con etiquetas de seguridad FHIR. La colección incluye solicitudes de ejemplo y orientaciones sobre cómo probar el enmascaramiento y el filtrado de propiedades de datos sensibles en función de los permisos del usuario.

Ejecutar en Postman

El servidor FHIR Aidbox está disponible de forma gratuita para desarrollo y pruebas, por lo que puede configurar su propia instancia y experimentar con las etiquetas de seguridad en un entorno real. Esto facilita evaluar el funcionamiento de las etiquetas de seguridad en la práctica antes de considerar su uso en producción.

Véase también: RBAC con Keycloak y SMART on FHIR V2.