Modelo de datos de acceso y sistema de control de FHIR

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 opciones de un consumidor de atención médica. Permite o rechaza que un conjunto de actores realice acciones que afecten al consumidor para un propósito específico en un entorno determinado 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 del registro de salud electrónico (EHR) del consumidor. Sin embargo, a los efectos del consentimiento en la API de Cloud Healthcare, el enfoque se centra en las acciones relacionadas con el acceso a los datos, y la aplicación forzosa de esas acciones se limita a la lectura de datos de FHIR desde 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 se encuentren en el estado activo. Los consentimientos en cualquier otro estado no tienen efecto en la aplicación. 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 tantos datos como defina el compartimiento del paciente (STU3, R4).

  • Política de administrador: No está asociada 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 especificados por los criterios de recursos. La política de administrador establece la política predeterminada para todos los recursos de vinculación en la tienda.

  • Política de encadenamiento del administrador: Es un tipo de política del 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 del 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 admite paciente (STU3, R4) o encuentro (STU3, R4) como base del compartimento.
    • El almacén de FHIR en el que se aplica la política debe tener disableReferentialIntegrity configurado como false.

Puedes combinar tipos de políticas en el mismo nivel de recursos 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 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 fines de tratamiento 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 de 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 las 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ódigos:

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

    • ActCode: Es la coincidencia exacta de cadenas 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 (#3) usa un token externo con el alcance del consentimiento (izquierda) 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 una tienda del 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}: Una propiedad purpose en la que value es miembro del conjunto de valores 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: La función Romper 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 revisión posterior a la auditoría. Como resultado, btg requiere al menos un actor.
  • bypass: Permite que usuarios de confianza (como un administrador) o aplicaciones de confianza (como una canalización de entrenamiento de IA) operen en la tienda 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 acceso

En un entorno de atención médica complejo en el que coexisten varias políticas y consentimientos, aplicar el acceso y determinar los permisos de acceso puede ser una tarea desalentadora. Las diferentes partes interesadas pueden tener expectativas y requisitos diferentes con respecto al uso y la divulgación de la información del paciente. Para navegar por este panorama intrincado, es necesario comprender claramente cómo se aplica el acceso y la lógica subyacente que rige la determinación del acceso.

Un usuario de atención médica, como un paciente o un administrador, puede tener varias directivas de consentimiento contenidas en un solo recurso. 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 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 y como máximo un entorno por entrada de aprovisionamiento.

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

  • A todos los recursos se les niega el acceso de forma predeterminada si no hay una directiva que coincida.

  • Si el recurso solicitado no existe, solo se pueden identificar el tipo de recurso y el ID del recurso. Si 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 compartimiento de pacientes o al compartimiento de encuentros, se deniega el acceso.

    • En caso contrario:

      • Si hay una política de administrador que rechaza los criterios del acceso, independientemente de los otros criterios de recursos, se denegará el acceso.

      • Si hay una política de administrador que permite los criterios de la persona que accede para los criterios de recursos identificables (es decir, el tipo de recurso y el ID de recurso), se muestra un error que indica que no se encontró el recurso.

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

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

  • Solo las políticas del administrador determinan los recursos que no pertenecen a ningún paciente.

  • Los recursos que se encuentran en el compartimiento de pacientes (STU3, R4) o en el compartimiento de encuentros (STU3, R4) necesitan al menos una directiva de consentimiento de permiso por paciente o política de administrador o política de administrador en cascada, y no deben tener directivas de consentimiento de rechazo de la política de paciente y administrador y política de administrador en cascada. Esta condición es necesaria para todos los pacientes nombrados en los recursos a los que el solicitante accederá.

    • Algunos recursos pueden admitir varios participantes de pacientes. Por ejemplo, Cita proporciona una lista de participantes que pueden ser pacientes. Todos los pacientes nombrados en esos recursos deben permitir el acceso a la persona que accede a través de las directivas de consentimiento; de lo contrario, los recursos no se muestran. Si un recurso tiene un permiso de una política de derivación de encuentros, 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 de cada recurso. Cualquier referencia en un recurso no se resuelve ni se aplica en cascada para fines de verificación de acceso con 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 debido a la privacidad del paciente. En este caso, el profesional puede ver todo el recurso MedicationRequest, que incluye un campo subject que hace referencia al recurso Patient/f001, pero no puede ver el contenido de la Patient/f001, incluso, 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 el 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 de consentimiento se basa en los permisos de consentimiento proporcionados en la solicitud, en función de las directivas de consentimiento que capturó 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.Encounter-everything, fhir.executeBundle o fhir.search), se aplica la aplicación forzosa del 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 y fhir.Encounter-everything se comportan de manera similar a fhir.search, excepto que muestran “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 o encuentro solicitado, respectivamente.

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 la persona que accede, en cuyo caso cualquier valor de propiedad del permiso 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 permiso del consentimiento también debe coincidir con las directivas de consentimiento que no especifican estos tipos de permiso.

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?