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 capta las elecciones de los consumidores de servicios de salud. 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 de solo los datos de la historia clínica electrónica (HCE) del consumidor. fines de consentimiento dentro de la API de Cloud Healthcare, la atención se centra en las acciones relacionados con el acceso a los datos y la aplicación de esas acciones está limitada para leer datos de FHIR desde un almacén de FHIR.

Un recurso de consentimiento tiene un estado que indique el estado actual del consentimiento. Aunque un almacén de FHIR puede contienen muchos consentimientos en diferentes estados, solo la API de Cloud Healthcare aplica consentimientos que están en estado active. 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 que usa Consent.patient. (STU3, R4). y vincula tantos datos como lo define el compartimento 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. Esta el tipo de política podría vincularse a un subconjunto o a todos los recursos del almacén especificado según 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 en cascada 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 de administración. Puedes vincular este tipo de política a un compartimento recursos que coinciden 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 se define 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 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

  • Objetivo: ETREAT 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 FHIR, mientras que 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 indica en el campo meta.security (STU3, R4). Se admiten los siguientes sistemas de código:

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

    • ActCode: la 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 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. Ejemplos de type y value incluyen:

    • 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: Romper el vidrio (o BTG) te permite, como usuario humano, omitir el consentimiento. controles de seguridad en caso de emergencias. Solo debe usarse en emergencias y es sujetos a una revisión posterior a la auditoría. Como resultado, btg requiere al menos una actor
  • bypass: Permite a los usuarios de confianza (como un administrador) o a usuarios de confianza. aplicaciones (como una canalización de entrenamiento de AA) para que operen en el almacén 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 hay varias políticas y consentimientos coexistir, aplicar el acceso y determinar los permisos de acceso puede ser una tarea abrumadora tarea. Varios interesados pueden tener diferentes expectativas y requisitos respecto al uso y la divulgación de información de los pacientes. Para navegar por este panorama complejo, es necesario comprender claramente cómo se aplica el acceso y la lógica subyacente que rige la determinación del acceso.

Un consumidor de atención médica, como un paciente o un administrador, puede tener varias directivas de consentimiento incluidas en un solo recurso de consentimiento. Recursos de consentimiento puede contener una combinación de permit y deny provision.type directivas. 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 uno como máximo propósito y, como máximo, un entorno por aprovisionar entrada.

Las siguientes reglas describen los principios para el control de acceso conjunto de consentimiento del paciente, política del administrador y 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 el tipo y el ID del recurso sean identificables. Todos los demás criterios de recursos y el propietario del recurso son desconocido, se aplica la siguiente regla en el orden de la ficha:

    • Si el tipo de recurso pertenece al compartimento o al find-compartment: Se denegó el acceso.

    • En caso contrario:

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

      • Si existe una política administrativa que permita los criterios de acceso para la los criterios de recursos identificables (es decir, tipo e ID de recurso), un "no se encontró el recurso" se muestra un error de aplicación.

      • 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.

  • Solo el administrador determina los recursos que no pertenecen a ningún paciente. y políticas de seguridad.

  • Recursos en el compartimento para pacientes (STU3, R4) o buscar un compartimento (STU3, R4) necesitan al menos una directiva de consentimiento de permiso por paciente o política de administración o política en cascada del administrador y directiva de no denegación del consentimiento del paciente y la política de administración y la política de administración en cascada del administrador. Esta de salud de todos los pacientes nombrados en los recursos que se a las que accede el solicitante.

    • Algunos recursos pueden admitir varios participantes de pacientes. Por ejemplo, Cita proporciona una lista de participantes que pueden ser pacientes. Todos los pacientes que se nombran los recursos deben permitir el acceso al descriptor de acceso usando directivas de consentimiento, De lo contrario, los recursos no se devuelven. Si un recurso tiene un permiso de una política de cascada de encuentros, en la que este encuentro hace referencia a un paciente a través del campo subject (STU3, R4), entonces se considera que el recurso está permitido por el paciente.

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 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 una Profesional para acceder a todo el recurso MedicationRequest, pero no a las Patient/f001 debido a la privacidad del paciente. En este caso, el El profesional puede ver el recurso MedicationRequest completo, con un subject que hace referencia al recurso Patient/f001, pero no puede ver el del recurso Patient/f001, por ejemplo, cuando se realizan 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 Google Cloud cuenta de servicio (o la principal) configurada en el proxy. Si el 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 estas políticas se basa sobre los permisos de consentimiento incluidos en la solicitud, de conformidad con la directivas 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. Consentimiento parcial no especifican las tres propiedades del descriptor de acceso, en cuyo caso el valor de la propiedad del alcance del consentimiento puede coincidir según 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?