Modelo de datos de acceso y sistema de control de FHIR

En esta página se describe cómo usar el sistema de control de acceso FHIR de la API Cloud Healthcare para gestionar y proteger sus datos sanitarios. Puedes usar el control de acceso FHIR para definir políticas de consentimiento, controlar el acceso a los datos en función de los roles y el contexto de los usuarios, y aplicar estas políticas en un almacén FHIR.

Descripción general del modelo de datos

El modelo de datos para el control de acceso se representa mediante recursos de consentimiento. Definen las reglas que se aplican y a qué datos se aplican.

Las reglas de acceso se expresan mediante recursos Consentimiento de FHIR. Consentimiento de FHIR es un tipo de recurso de FHIR que registra las decisiones de los consumidores de servicios sanitarios. Permite o deniega a un conjunto de actores realizar acciones que afecten al consumidor con un propósito específico desde un entorno determinado durante un periodo. Por ejemplo, un consumidor puede ser un paciente, cualquier persona que actúe en nombre de un paciente o cualquier otra persona que firme un contrato de consentimiento.

Las acciones registradas en un consentimiento de FHIR pueden ser amplias y abarcar más que los datos del historial médico electrónico (HME) del consumidor. Sin embargo, a efectos del consentimiento en la API Cloud Healthcare, nos centramos en las acciones relacionadas con el acceso a los datos, y la aplicación de esas acciones se limita a la lectura de datos FHIR de un almacén FHIR.

Un recurso Consent tiene un status que indica el estado actual del consentimiento. Aunque un almacén FHIR puede contener muchos consentimientos en diferentes estados, la API Cloud Healthcare solo aplica los consentimientos que están en el estado activo. Los consentimientos en cualquier otro estado no tienen ningún efecto en la aplicación. Si se da el consentimiento en nombre de un paciente, se registra como concedido por un profesional sanitario.

Tipo de política

La API Cloud Healthcare admite los siguientes tipos de políticas de consentimiento:

  • Consentimiento del paciente: se asocia a un paciente que usa Consent.patient (STU3, R4) y vincula tantos datos como se definan en el compartimento del paciente (STU3, R4).

  • Política de administrador: no está asociada a ningún paciente y debe tener una URL de extensión https://g.co/fhir/medicalrecords/ConsentAdminPolicy. Este tipo de política se puede vincular a un subconjunto o a todos los recursos de la tienda especificada por los criterios de recursos. La política de administrador define la política predeterminada de todos los recursos de vinculación del almacén.

  • Política en cascada de administrador: un tipo de política de administrador que requiere la URL de la extensión https://g.co/fhir/medicalrecords/CascadingPolicy y la URL de la extensión de la política de administrador. Puedes asociar este tipo de política a un compartimento de recursos que cumplan los criterios de recursos. Tiene las siguientes limitaciones:

Puedes combinar tipos de políticas en el mismo nivel de recurso para permitir o denegar el acceso a un recurso. Si falta el consentimiento de un paciente, la política de administrador puede aprobar el acceso a un recurso.

Las directivas de consentimiento son instrucciones codificadas en un consentimiento de FHIR que permiten o deniegan el acceso a los datos a una entidad autorizada, como un beneficiario o un accesorio. Un solo consentimiento de FHIR puede codificar varias directivas de consentimiento. Cada directiva proporciona lo siguiente:

  • Tipo de cumplimiento: una instrucción permit o deny.

  • Acción: los permisos cubiertos por esta directiva. Solo se admite access para proporcionar acceso de solo lectura.

  • Criterios de acceso: conjunto de atributos que identifican al solicitante de la API cubierto por la directiva.

  • Criterios de recursos: un conjunto de atributos que identifican los recursos cubiertos por la directiva.

Criterios de accesibilidad

La API Cloud Healthcare admite tres propiedades de un accessor para usarlo en una directiva de consentimiento y para compararlo con un accessor que haga una solicitud de acceso a datos. Debe haber una coincidencia exacta que distinga entre mayúsculas y minúsculas para que se aplique una directiva al accessor como parte de la determinación de acceso que ofrece el servidor FHIR.

Estas propiedades se codifican de la siguiente manera:

  • Actor: representa a una persona, un grupo o un rol de acceso que identifica al elemento que accede o una característica de este.

  • Finalidad: representa la intención de uso de los datos.

  • Entorno: representa un identificador abstracto que describe el entorno o las condiciones en las que actúa el accesor.

Por ejemplo, un accesor puede representarse mediante las siguientes propiedades:

  • Remitente: Practitioner/123

  • Finalidad: ETREAT o acceso con fines de tratamiento de emergencia

  • Entorno: Application/abc

En este ejemplo, estas propiedades representan a un médico que accede a los datos cuando realiza un tratamiento de emergencia con una aplicación de software llamada abc.

provision.actor y provision.purpose se definen como parte del estándar FHIR, mientras que Environment es https://g.co/fhir/medicalrecords/Environment. Ten en cuenta que este enlace no se puede resolver.

Todas las directivas de consentimiento deben especificar un actor que se aplique, pero no siempre tienen que especificar un purpose o un environment. Por ejemplo, si no se especifica ningún environment en la directiva de consentimiento, esta coincidirá con cualquier environment que no esté cubierto por otras directivas de consentimiento.

Criterios de recursos

La API Cloud Healthcare admite los siguientes elementos como parte del recurso Consent:

  • Tipo de recurso (STU3, R4): representa el tipo al que se vincula la política de consentimiento. Por ejemplo, Encounter, Observation o Immunization.

  • ID de recurso (STU3, R4): representa el ID al que se vincula la política de consentimiento.

  • Fuente de datos: representa el origen del recurso tal como lo identifica el recurso meta.source (solo disponible en R4).

  • Etiqueta de datos: representa la etiqueta personalizada del recurso, tal como se describe en el recurso meta.tag (STU3, R4).

  • Etiqueta de seguridad: representa las etiquetas de seguridad que definen los recursos afectados, tal como se indica en el campo meta.security (STU3 y R4). Se admiten los siguientes sistemas de códigos:

    • Confidencialidad: valores jerárquicos ordenados de menos a más restringidos: U, L, M, N, R y V. Si un consentimiento permite una etiqueta de seguridad de R, se aplica a todos los recursos que tengan la etiqueta R o una inferior. Si un consentimiento deniega una etiqueta de seguridad R, se aplica a todos los recursos que sean al menos tan sensibles como R.

    • ActCode coincidencia exacta de la cadena del código de seguridad.

Acceder al flujo de trabajo

authorization_flow

En esta figura se ilustra el recorrido completo de una solicitud a un almacén con el control de acceso de FHIR habilitado. La aplicación (#3) usa un token externo con el ámbito de consentimiento (izquierda) cuando hace una solicitud al almacén de FHIR con el control de acceso habilitado (derecha).

Cuando se hace una solicitud de acceso a datos, un accessor opera en un Consent Scope concreto que representa sus propiedades actor, purpose y environment relacionadas con cualquier solicitud HTTP de FHIR. Los valores de estas propiedades deben coincidir exactamente con los proporcionados en un consentimiento para que afecten a la determinación del acceso de la medida.

Un accesor puede tener varios identificadores actor relevantes para determinar el acceso. Del mismo modo, puede haber varios purposes o environments que sean relevantes en un contexto de consentimiento concreto. Por lo tanto, todas las propiedades de acceso pertinentes deben proporcionarse como parte de una solicitud HTTP de FHIR para representar correctamente ese acceso con fines de consentimiento.

Por ejemplo, el ámbito del consentimiento de una solicitud de datos determinada puede ser el siguiente:

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

Representa a un enfermero o un médico, conocido como profesional sanitario 444, que es miembro del grupo 999, que representa a los profesionales sanitarios de un departamento de un hospital concreto. El profesional sanitario está ahí para proporcionar tratamiento periódico, pero también puede encargarse de tratamientos de emergencia como parte de estas acciones. El profesional sanitario utiliza una aplicación de software llamada abc.

El ámbito del consentimiento se proporciona como un ámbito de consentimiento de solicitud como parte de la solicitud de datos de un accesor.

Ámbito de la solicitud de consentimiento

Las solicitudes FHIR usan encabezados de solicitud HTTP de FHIR para recibir el ámbito de consentimiento del accesor. Este ámbito de consentimiento contiene un conjunto de valores actor, purpose y environment para reflejar la identidad, las cualificaciones, la intención de uso y las restricciones del entorno actuales del accesor. Puede haber más de una de cada una de estas propiedades que representen el ámbito del consentimiento de un accesor en un momento dado.

Las entradas de ámbito de consentimiento se definen de la siguiente manera:

  • actor/{type}/{ID}: propiedad actor en la que se proporciona el recurso type junto con el ID. Estos son algunos ejemplos de type:

    • Practitioner
    • Group
    • Patient

    Por ejemplo, si una tienda con el formato projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID llama a la API, una referencia local a un actor Practitioner/123 se resuelve como projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.

  • purp/v3/{value}: una propiedad purpose donde value es miembro del conjunto de valores FHIR Purpose of Use (v3) o de su extensión. Estos son algunos ejemplos de value:

    • TREAT
    • ETREAT
    • HRESCH

  • env/{type}/{value}: una propiedad environment donde type y value son cadenas personalizadas sin taxonomía predefinida. Estos son algunos ejemplos de type y value:

    • App/my_app_1
    • Net/VPN

Además, los encabezados de solicitud HTTP de FHIR también pueden recibir ámbitos especiales, como btg y bypass, que se definen de la siguiente manera:

  • btg: la función de acceso de emergencia te permite, como usuario humano, saltarte las comprobaciones de consentimiento en caso de emergencia. Solo debe usarse en caso de emergencia y está sujeta a una revisión posterior. Por lo tanto, btg requiere al menos un elemento actor.
  • bypass: permite que usuarios de confianza (como un administrador) o aplicaciones de confianza (como una canalización de entrenamiento de aprendizaje automático) operen en el almacén de FHIR sin autorización de consentimiento. Por lo tanto, bypass requiere al menos un actor y un env.

Aplicación y determinación del acceso

En un entorno sanitario complejo en el que coexisten varias políticas y consentimientos, aplicar el acceso y determinar los permisos de acceso puede ser una tarea difícil. Las distintas partes interesadas pueden tener expectativas y requisitos diferentes en cuanto al uso y la divulgación de la información de los pacientes. Para moverse por este complejo panorama, es necesario comprender claramente cómo se aplica el acceso y la lógica subyacente que rige la determinación del acceso.

Un consumidor del sector sanitario, como un paciente o un administrador, puede tener varias directivas de consentimiento en un solo recurso Consent. Los recursos de consentimiento pueden contener una combinación de directivas permit y deny provision.type. De forma predeterminada, un usuario puede tener cualquier número de recursos Consent, pero se aplican hasta 200 recursos active Consent a la vez. Consulta Restricciones y limitaciones para obtener más información.

Todas las directivas de consentimiento se extraen de los recursos de consentimiento de un usuario concreto para crear un conjunto de reglas de consentimiento agregadas.active

La aplicación del consentimiento se limita a un propósito como máximo y a un entorno como máximo por cada entrada de provision.

Las siguientes reglas describen los principios del control de acceso conjunto del consentimiento del paciente, la política de administrador y la política de administrador en cascada:

  • De forma predeterminada, se deniega el acceso a todos los recursos si no hay ninguna directiva coincidente.

  • Si el recurso solicitado no existe, solo se pueden identificar el tipo y el ID del recurso. Si se desconocen el resto de los criterios de recursos y el propietario del recurso, se aplica la siguiente regla en el orden de la lista:

    • Si el tipo de recurso pertenece al compartimento del paciente o al compartimento de la consulta, se deniega el acceso.

    • En caso contrario:

      • Si hay una política de administrador que deniega los criterios del elemento de acceso, independientemente de los demás criterios del recurso, se deniega el acceso.

      • Si hay una política de administrador que permite los criterios de acceso para los criterios de recursos identificables (es decir, el tipo de recurso y el ID de recurso), se devuelve un error "recurso no encontrado".

      • En el resto de los casos, se deniega el acceso.

  • Las políticas de administrador son las políticas predeterminadas que se usan para asociar recursos en la tienda.

  • Los recursos que no pertenecen a ningún paciente se determinan únicamente por las políticas de administrador.

  • Los recursos que se encuentran en el compartimento del paciente (STU3 y R4) o en el compartimento de la consulta (STU3 y R4) necesitan al menos una directiva de consentimiento permitida por paciente o política de administrador o política de administrador en cascada, y ninguna directiva de consentimiento denegada por paciente y política de administrador y política de administrador en cascada. Esta condición es necesaria para todos los pacientes que se mencionan en los recursos a los que debe acceder el solicitante.

    • Algunos recursos pueden admitir varios participantes pacientes. Por ejemplo, Cita proporciona una lista de participantes, que pueden ser pacientes. Todos los pacientes mencionados en dichos recursos deben permitir el acceso al accessor mediante directivas de consentimiento. De lo contrario, los recursos no se devuelven. Si un recurso tiene un permiso de una política en cascada de un encuentro, donde este encuentro hace referencia a un paciente a través del campo subject (STU3, R4), se considera que el paciente permite el recurso.

Las reglas descritas se resumen en el siguiente pseudocódigo:

Control de acceso conjunto

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

El almacén FHIR comprueba el permiso de consentimiento a nivel de recurso. No se resuelve ni se aplica en cascada ninguna referencia de un recurso para comprobar el acceso con consentimiento. Por ejemplo, supongamos que un paciente identificado por Patient/f001 permite que un profesional sanitario acceda a todo su recurso MedicationRequest, pero no al recurso Patient/f001 en sí debido a la privacidad del paciente. En este caso, el profesional sanitario puede ver todo el recurso MedicationRequest, que incluye un campo subject que hace referencia al recurso Patient/f001, pero no puede ver el contenido del recurso Patient/f001, aunque, por ejemplo, realice una búsqueda de FHIR con _include.

Resolución de conflictos

Es posible que haya conflictos entre varias directivas permit y deny. Si dos directivas en conflicto coinciden con un recurso, el conflicto se resuelve mediante el modelo deny gana a permit.

Solo se incluyen los consentimientos de active para aplicar el consentimiento.

Lógica de aplicación del acceso a recursos

Cuando se hace una solicitud que tiene en cuenta el consentimiento a un almacén FHIR, el control de acceso se produce en el siguiente orden:

  1. La API Cloud Healthcare comprueba los permisos de la Google Cloud cuenta de servicio (o la entidad de seguridad) configurada en el proxy. Si la cuenta de servicio tiene los permisos de gestión de identidades y accesos correctos para realizar el método FHIR solicitado en el almacén FHIR, la solicitud se procesa.

  2. Si la aplicación del consentimiento está habilitada en la configuración del almacén FHIR y están presentes los encabezados HTTP que tienen en cuenta el consentimiento, la API Cloud Healthcare aplica las políticas de acceso con consentimiento a los recursos de PatientCompartment. La aplicación de las políticas de acceso con consentimiento se basa en los ámbitos de consentimiento proporcionados en la solicitud, de acuerdo con las directivas de consentimiento registradas en la ejecución más reciente de ApplyConsents y ApplyAdminConsents.

Se aplican las siguientes reglas al enviar una solicitud que tiene en cuenta el consentimiento a un almacén FHIR:

  • Proporcione al menos un ámbito de consentimiento actor relevante para las acciones de consentimiento realizadas.

  • Proporcione los ámbitos purpose y environment adicionales que sean relevantes para las acciones de consentimiento realizadas.

  • Si el número de entradas de ámbito de consentimiento supera los límites admitidos, se devuelve un error.

  • Si llamas a un método que accede a varios recursos (por ejemplo, los métodos fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle o fhir.search), la aplicación del consentimiento se aplica a cada recurso individual. Sin embargo, hay una diferencia sutil entre estos métodos de acceso a varios recursos:

    • fhir.executeBundle lee varios recursos y recibe el mensaje "Acceso denegado por falta de consentimiento o el recurso al que se accede no existe" para un recurso concreto sin permisos de consentimiento (consulta ejemplos en Obtener recursos FHIR con ámbito de consentimiento).

    • fhir.search omite los recursos sin permisos de consentimiento y no devuelve el error de acceso denegado por consentimiento, ni siquiera al buscar por _id (consulta los ejemplos en Buscar recursos FHIR con ámbito de consentimiento).

    • fhir.Patient-everything y fhir.Encounter-everything se comportan de forma similar a fhir.search, excepto que devuelven "Consent access denied or the resource being accessed does not exist" (Acceso denegado o el recurso al que se accede no existe) si la persona que llama no tiene permiso de consentimiento en el recurso Patient o Encounter solicitado, respectivamente.

Una directiva de consentimiento tiene como máximo un actor, un purpose y un environment, mientras que el ámbito del consentimiento puede tener varios de cada uno. Algunas directivas de consentimiento no especifican las tres propiedades de acceso, en cuyo caso puede coincidir cualquier valor de propiedad de ámbito de consentimiento en función de las reglas de resolución de conflictos. Por lo tanto, un ámbito de consentimiento puede coincidir con más de una directiva de consentimiento.

Si el ámbito de consentimiento de una solicitud incluye dos o más entradas del mismo tipo de ámbito de consentimiento (actor, purpose o environment), es posible que el ámbito de consentimiento coincida con varias directivas de consentimiento. Algunas directivas de consentimiento no especifican un purpose o un environment. Por lo tanto, el ámbito del consentimiento también debe coincidir con las directivas de consentimiento que no especifiquen estos tipos de ámbito.

Por ejemplo, si se define el ámbito del consentimiento como actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc, se comparará con cualquiera de las siguientes directivas de consentimiento:permit o deny.

  • actor/Practitioner/123 purp/v3/TREAT env/App/abc
  • actor/Practitioner/123 purp/v3/TREAT
  • actor/Practitioner/123 env/App/abc
  • actor/Practitioner/123
  • actor/Group/999 purp/v3/TREAT env/App/abc
  • actor/Group/999 purp/v3/TREAT
  • actor/Group/999 env/App/abc
  • actor/Group/999

Siguientes pasos