Modelo de datos de acceso a FHIR y sistema de control

Descripción general del modelo de datos

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

Las reglas de acceso se expresan a través de los recursos de Consentimiento de FHIR. El consentimiento de FHIR es un tipo de recurso de FHIR que captura las elecciones de un consumidor de atención médica. Permite o niega que un conjunto de actores realice acciones que afecten al consumidor para un propósito específico desde un entorno específico durante un período. Por ejemplo, un consumidor puede ser un paciente, cualquier persona que actúe en nombre de un paciente o cualquier otra persona que acepte un acuerdo de consentimiento.

Las acciones registradas en un consentimiento de FHIR pueden ser amplias y abarcar más que solo los datos de registros de salud electrónicos (EHR) del consumidor. Sin embargo, para los fines de consentimiento dentro de la API de Cloud Healthcare, el enfoque está en las acciones relacionadas con el acceso a los datos y la aplicación de esas acciones se limita a la lectura de los datos de FHIR de un almacén de FHIR.

Un recurso de consentimiento tiene un estado que indica el estado actual del consentimiento. Aunque un almacén de FHIR puede contener muchos consentimientos en diferentes estados, la API de Cloud Healthcare solo aplica consentimientos que están en estado activo. Los consentimientos en cualquier otro estado no afectan la aplicación forzosa. Si se otorga un consentimiento en nombre de un paciente, se registra como si lo otorgara un ejecutor.

Tipo de política

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

  • Consentimiento del paciente: Se asocia con un paciente mediante Consent.patient (STU3, R4) y vincula todos los datos que define el compartimento del paciente (STU3, R4).

  • Política del administrador: no se asocia con ningún paciente y debe tener una URL de extensión https://g.co/fhir/medicalrecords/ConsentAdminPolicy. Este tipo de política podría vincularse a un subconjunto o a todos los recursos del almacén que especifican los criterios de recursos. La política del administrador establece la política predeterminada para todos los recursos de vinculación en el almacén.

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

    • Solo es compatible con pacientes (STU3, R4) o Encounter (STU3, R4) como base del compartimento.
    • El almacén de FHIR en el que se aplica la política debe tener disableReferentialIntegrity establecido en false.

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 administración puede aprobar el acceso a un recurso.

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

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

  • Acción: Los permisos que abarcan esta directiva. Solo access es compatible para proporcionar acceso de solo lectura.

  • Criterios de la persona que accede: Un conjunto de atributos que identifican al solicitante de la API con la cobertura de la directiva.

  • Criterios de recursos: Un conjunto de atributos que identifican los recursos que cubre la directiva.

Criterios de la persona que accede

La API de Cloud Healthcare admite tres propiedades de una persona que accede, que se usarán dentro de una directiva de consentimiento, y para que coincidan con un usuario que realiza una solicitud de acceso a los datos. Debe existir una concordancia exacta que distinga entre mayúsculas y minúsculas para que se aplique una directiva a la persona que accede como parte de la determinación del acceso que ofrece el servidor de FHIR.

Estas propiedades están codificadas de la siguiente manera:

  • Actor: representa una función individual, grupal o de acceso que identifica a la persona que accede o a una de sus características.

  • Propósito: Representa el intent de uso de los datos.

  • Entorno: Representa un identificador abstracto que describe el entorno o las condiciones en las que actúa la persona que accede.

Por ejemplo, una persona que accede puede estar representada por las siguientes propiedades:

  • Actor: Practitioner/123

  • Propósito: ETREAT o acceso para tratamientos de emergencia

  • Entorno: Application/abc

En este ejemplo, estas propiedades representan 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 el entorno es https://g.co/fhir/medicalrecords/Environment. Ten en cuenta que este vínculo no se puede resolver.

Todas las directivas del consentimiento deben especificar un actor para que se aplique, aunque no siempre especifican un purpose o un environment. Por ejemplo, si no se especifica ningún environment en la directiva de consentimiento, entonces esta coincide con cualquier environment que no esté cubierta por otras directivas de consentimiento.

Criterios de recursos

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

  • Tipo de recurso (STU3, R4): Representa el tipo a el 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 según lo identifica el recurso meta.source (solo disponible en R4).

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

  • Etiqueta de seguridad: Representa etiquetas de seguridad que definen los recursos afectados como se identifica en el campo meta.security (STU3, R4). Se admiten los siguientes sistemas de código:

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

    • ActCode: Coincidencia exacta de cadena en el código de seguridad

Flujo de trabajo de acceso

authorization_flow

En esta figura, se ilustra el recorrido de extremo a extremo de una solicitud a un almacén habilitado para el control de acceso de FHIR. La aplicación usa un token externo con el permiso de consentimiento (izquierda) (n.o 3) cuando realiza una solicitud al almacén de FHIR con el control de acceso habilitado (derecha).

Cuando realiza una solicitud de acceso a los datos, una persona que accede opera dentro de un permiso de consentimiento particular que representa sus propiedades actor, purpose y environment relacionadas con cualquier solicitud HTTP de FHIR. Los valores de estas propiedades deben ser una opción que distinga mayúsculas de minúsculas y que coincida con los que se proporcionan dentro del consentimiento otorgado para que influyan en la determinación del acceso de la aplicación.

Una persona que accede puede tener varios identificadores actor que sean relevantes para realizar una determinación de acceso. Del mismo modo, puede haber varias purposes o environments que sean relevantes dentro de un contexto de consentimiento en particular. Por lo tanto, todas las propiedades relevantes de la persona que accede deben proporcionarse como parte de una solicitud HTTP de FHIR para representar correctamente a esa persona, con fines de consentimiento.

Por ejemplo, el alcance del consentimiento para una solicitud de datos determinada puede ser el siguiente:

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

Esto representa a una enfermera o un médico conocido como profesional 444 que es miembro del grupo 999, que representa a los profesionales de un departamento dentro de un hospital específico. El profesional está disponible para brindar un tratamiento habitual, pero es posible que también maneje los tratamientos de emergencia como parte de estas acciones. El profesional usa una aplicación de software llamada abc.

El permiso de consentimiento se proporciona como un permiso de consentimiento de solicitud como parte de la solicitud de datos del usuario que accede.

Alcance del consentimiento de la solicitud

Las solicitudes de FHIR usan encabezados de solicitud HTTP de FHIR para recibir el permiso de consentimiento de la persona que accede. Este permiso de consentimiento contiene un conjunto de valores actor, purpose y environment para reflejar la identidad actual, las calificaciones, la intención de uso y las restricciones del entorno en las que opera la persona que accede. Puede haber más de una de estas propiedades que representen el permiso del consentimiento de una persona que accede al mismo tiempo.

Las entradas del permiso del consentimiento se definen de la siguiente manera:

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

    • Practitioner
    • Group
    • Patient

    Por ejemplo, si un almacén 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 en projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.

  • purp/v3/{value}: Es una propiedad purpose en la que value es miembro del conjunto de valores de Propósito de uso de FHIR (v3) o su extensión. Estos son algunos ejemplos de value:

    • TREAT
    • ETREAT
    • HRESCH

  • env/{type}/{value}: Una propiedad environment en la que type y value son strings 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 alcances especiales, como btg y bypass, que se definen de la siguiente manera:

  • btg: Rompe el vidrio (o BTG) te permite, como usuario humano, omitir las verificaciones de consentimiento en caso de emergencias. Solo debe usarse en emergencias y está sujeto a una revisión posterior a la auditoría. Como resultado, btg requiere al menos un actor.
  • bypass: Permite que los usuarios de confianza (como un administrador) o las aplicaciones de confianza (como una canalización de entrenamiento del AA) 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 de accesos

En un entorno de atención médica complejo en el que coexisten varias políticas y consentimientos, aplicar de manera forzosa el acceso y determinar los permisos de acceso puede ser una tarea abrumadora. Varias partes interesadas pueden tener expectativas y requisitos diferentes con respecto al uso y la divulgación de la información de los pacientes. Navegar por este panorama intrincado requiere una comprensión clara de cómo se aplica el acceso y la lógica subyacente que rige la determinación de acceso.

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

Todas las directivas de consentimiento se extraen de los recursos de consentimiento de active para que un usuario determinado realice un conjunto de reglas de consentimiento agregadas.

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

En las siguientes reglas, se describen los principios del control de acceso conjunto del consentimiento de los pacientes, la política del administrador y la política en cascada del administrador:

  • De forma predeterminada, se deniega el acceso a todos los recursos si no hay directivas que coincidan.

  • Si el recurso solicitado no existe, solo se pueden identificar el tipo y el ID del recurso. Se desconocen todos los demás 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 para pacientes o al compartimento de encuentro, se deniega el acceso.

    • En caso contrario:

      • Si hay una política del administrador que niega los criterios de acceso, sin importar los otros criterios de los recursos, el acceso se rechaza.

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

      • En todos los demás casos, se deniega el acceso.

  • Las políticas de administración son las políticas predeterminadas que se usan para hacer coincidir los recursos en el almacén.

  • Los recursos que no pertenecen a ningún paciente están determinados solo por las políticas del administrador.

  • Los recursos que se encuentran en el compartimento de pacientes (STU3, R4) o en el compartimento (STU3, R4) necesitan al menos una directiva de consentimiento de permiso por paciente o una política de administración o una política de administración en cascada y una directiva de no denegar de consentimiento del paciente y la política de administración en cascada y la política en cascada del administrador. Esta condición es necesaria para todos los pacientes nombrados en los recursos a los que el solicitante pueda acceder.

    • Algunos recursos pueden admitir varios participantes de pacientes. Por ejemplo, Appointment, proporciona una lista de participantes que pueden ser pacientes. Todos los pacientes nombrados en dichos recursos deben permitir el acceso al descriptor de acceso mediante directivas de consentimiento; de lo contrario, los recursos no se mostrarán. Si un recurso tiene un permiso de una política en cascada de encuentro, en la que 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 de FHIR verifica el permiso de consentimiento a nivel por recurso. Cualquier referencia en un recurso no se resuelve y se transmite en cascada para fines de verificación de acceso de consentimiento. Por ejemplo, considera un paciente identificado por Patient/f001 que permite que un profesional acceda a todo su recurso MedicationRequest, pero no al recurso Patient/f001 en sí, debido a su privacidad. En esta situación, el profesional puede ver el recurso MedicationRequest completo, que incluye un campo subject que hace referencia al recurso Patient/f001, pero no puede ver el contenido del recurso Patient/f001, por ejemplo, cuando realiza una búsqueda de FHIR con _include.

Resolución de conflictos

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

Solo se incluyen los consentimientos de active para la aplicación del consentimiento.

Lógica de aplicación del acceso a los recursos

Cuando se realiza una solicitud de consentimiento adaptado a un almacén de FHIR, el control de acceso se produce en el siguiente orden:

  1. La API de Cloud Healthcare verifica los permisos en la cuenta de servicio de Google Cloud (o la principal) configurada en el proxy. Si la cuenta de servicio tiene los permisos de IAM correctos para realizar el método de FHIR solicitado en el almacén de FHIR, la solicitud continúa.

  2. Si la aplicación de consentimiento está habilitada en la Configuración del almacén de FHIR y los encabezados HTTP adaptados al consentimiento, entonces la API de Cloud Healthcare aplica políticas de acceso de consentimiento para los Recursos del compartimiento de pacientes. La aplicación de las políticas de acceso al consentimiento se basa en los permisos de consentimiento proporcionados en la solicitud, de acuerdo con las directivas de consentimiento capturadas por la ejecución más reciente de ApplyConsents y ApplyAdminConsents.

Las siguientes reglas se aplican cuando se realiza una solicitud de consentimiento adaptado a un almacén de FHIR:

  • Proporciona al menos un permiso de consentimiento de actor relevante para las acciones de consentimiento que se realizan.

  • Proporciona los alcances purpose y environment adicionales relevantes para las acciones de consentimiento realizadas.

  • Se muestra un error si la cantidad de entradas del permiso de consentimiento supera los límites admitidos.

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

    • fhir.executeBundle que lee varios recursos recibe “Acceso de consentimiento denegado o el recurso al que se accede no existe” para recursos individuales sin los permisos de consentimiento (consulta ejemplos en la sección Obtén recursos de FHIR con permiso de consentimiento).).

    • fhir.search omite recursos sin permisos de consentimiento y no muestra un error de acceso denegado, incluso para buscar por _id (consulta ejemplos en la Búsqueda de recursos FHIR con permiso de consentimiento).

    • fhir.Patient-everything se comporta de manera similar a fhir.search, excepto que muestra “Acceso de consentimiento denegado o el recurso al que se accede no existe” si el emisor no tiene el permiso de consentimiento del recurso de paciente solicitado.

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

Si el permiso del consentimiento de una solicitud incluye dos o más entradas del mismo tipo de permiso de consentimiento (actor, purpose o environment), el permiso de consentimiento puede coincidir con varias directivas de consentimientos. Algunas directivas de consentimiento no especifican un purpose ni un environment. Por lo tanto, el alcance de consentimiento también debe coincidir con directivas de consentimiento que no especifican estos tipos de alcance.

Por ejemplo, configurar el permiso del consentimiento como actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc coincide con cualquiera de las siguientes directivas de consentimiento de 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

¿Qué sigue?