Modelo de dados de acesso FHIR e sistema de controle

Visão geral do modelo de dados

O modelo de dados para controle de acesso é representado por recursos de consentimento. Eles definem as regras aplicáveis e a quais dados elas se aplicam.

As regras de acesso são expressas por meio de recursos de consentimento de FHIR. O consentimento para FHIR é uma tipo de Recurso FHIR que captura as escolhas do consumidor de saúde. Ele permite ou nega um conjunto de atores para realizar ações que afetam o consumidor para um propósito específico de um ambiente especificado durante um período. Por exemplo, um consumidor ser um paciente de saúde, qualquer pessoa que atue em nome de um paciente de saúde, ou outro indivíduo que celebre um contrato de consentimento.

As ações registradas em um consentimento FHIR podem ser amplas e lidar com mais de apenas os dados do histórico de saúde eletrônico (EHR) do consumidor. No entanto, para o para fins de consentimento na API Cloud Healthcare, o foco são as ações relacionadas ao acesso aos dados, e a aplicação dessas ações é limitada para ler dados FHIR de um repositório FHIR.

O recurso de consentimento tem status que indica o estado atual do consentimento. Um repositório FHIR pode contêm muitos consentimentos em diferentes estados, a API Cloud Healthcare só aplica consentimentos que estão no estado ativo; Consentimentos em qualquer outro estado não afetam a aplicação das políticas. Se o consentimento for dado em nome de paciente, o consentimento será registrado como concedido por um executor.

Tipo de política

A API Cloud Healthcare oferece suporte aos seguintes tipos de política de consentimento:

  • Consentimento do paciente: associado a um paciente que usa Consent.patient. (STU3, R4). e vincula quantos dados forem definidos pelo compartimento do paciente. (STU3, R4).

  • Política de administrador: não está associada a nenhum paciente e precisa ter um URL de extensão https://g.co/fhir/medicalrecords/ConsentAdminPolicy. Isso o tipo de política pode ser vinculado a um subconjunto ou a todos os recursos no armazenamento especificado pelos critérios de recursos. A política do administrador define o padrão política para todos os recursos de vinculação no armazenamento.

  • Política de administração em cascata: um tipo de política do administrador que exige o o URL de extensão https://g.co/fhir/medicalrecords/CascadingPolicy e o URL da extensão da política de administrador. É possível vincular esse tipo de política a um compartimento de recursos que correspondem aos critérios de recurso. Tem o seguintes limitações:

    • Oferece suporte apenas para Paciente (STU3, R4) ou Encounter (STU3, R4) como base de compartimento.
    • O armazenamento FHIR em que a política é aplicada precisa ter disableReferentialIntegrity definido como false.

É possível combinar tipos de políticas no mesmo nível de recurso para permitir ou negar o acesso a um recurso. Se o consentimento de um paciente estiver ausente, a política de administrador poderá aprovar o acesso a um recurso.

As diretivas de consentimento são instruções codificadas em um consentimento FHIR que Permitir ou negar o acesso a dados para uma entidade autorizada, como um beneficiário ou um accessor. Um único consentimento FHIR pode codificar várias diretivas de consentimento. Cada fornece o seguinte:

  • Tipo de aplicação: uma instrução permit ou deny.

  • Ação: as permissões abrangidas por esta diretiva. Somente access tem suporte para oferecer acesso somente leitura.

  • Critérios de acionador: um conjunto de atributos que identificam o solicitante da API coberto pela diretiva.

  • Critérios de recursos: um conjunto de atributos que identificam os recursos cobertos pela diretiva.

Critérios de acesso

A API Cloud Healthcare oferece suporte a três propriedades de um acessador para uso dentro de uma diretiva de consentimento e para fazer a correspondência com um acessador que faça a solicitação solicitação. É necessário ter uma correspondência exata que diferencia maiúsculas de minúsculas para que uma diretiva seja aplicada ao acessório como parte da determinação de acesso oferecida pelo servidor FHIR.

Essas propriedades são codificadas da seguinte forma:

  • Ator: representa uma função individual, de grupo ou de acesso que identifica o acessador ou uma característica dele.

  • Finalidade: representa a intenção de uso dos dados.

  • Ambiente: representa um identificador abstrato que descreve o ambiente ou as condições em que o acessório está agindo.

Por exemplo, um acessório pode ser representado pelas seguintes propriedades:

  • Agente: Practitioner/123

  • Objetivo: ETREAT ou acesso para tratamento emergencial

  • Ambiente: Application/abc

Nesse exemplo, essas propriedades representam um médico que está acessando dados ao realizar um tratamento de emergência usando um aplicativo de software chamado abc.

provision.actor e provision.purpose são definidos como parte do padrão FHIR, enquanto o Ambiente é https://g.co/fhir/medicalrecords/Environment. Esse link não é resolvível.

Todas as diretivas de consentimento precisam especificar um actor para ser aplicado, mas não precisam sempre especificar um purpose ou um environment. Por exemplo, se nenhuma environment for especificada na diretiva de consentimento, ela vai corresponder a qualquer environment que não esteja coberto por outras diretivas de consentimento.

Critérios de recursos

A API Cloud Healthcare oferece suporte aos seguintes elementos como parte do recurso de consentimento:

  • Tipo de recurso (STU3, R4): representa o tipo ao qual a política de consentimento é vinculada, por exemplo, Encounter, Observation ou Immunization.

  • ID do recurso (STU3, R4): representa o ID ao qual a política de consentimento é vinculada.

  • Fonte de dados: representa a origem do recurso conforme identificado pelo recurso meta.source (disponível apenas no R4).

  • Tag de dados: representa o rótulo personalizado do recurso, conforme descrito no o recurso meta.tag (STU3, R4).

  • Rótulo de segurança: representa rótulos de segurança que definem os recursos afetados. conforme identificado no campo meta.security. (STU3, R4). Há suporte para os seguintes sistemas de códigos:

    • Confidencialidade: valores hierárquicos classificados de irrestritos para os mais restritos: U, L, M, N, R e V. Se o consentimento permitir um rótulo de segurança de R ele será aplicado a todos os recursos rotulados como R ou inferiores. Se um consentimento negar um rótulo de segurança R, ele será aplicado a todos os recursos que sejam pelo menos tão sensíveis quanto R.

    • ActCode: string de correspondência exata no código de segurança.

Fluxo de trabalho de acesso

authorization_flow

Nesta figura, ilustramos a jornada completa de uma solicitação para um repositório com controle de acesso FHIR ativado. Um token externo com o escopo de consentimento (à esquerda) é usado pelo aplicativo (no 3) ao fazer uma solicitação ao repositório FHIR com o controle de acesso ativado (à direita).

Ao fazer uma solicitação de acesso a dados, um acessório opera em um determinado escopo de consentimento que representa as propriedades actor, purpose e environment relacionadas a qualquer solicitação HTTP do FHIR. Os valores dessas propriedades devem diferenciar maiúsculas de minúsculas e aquelas fornecidas no consentimento para afetar a determinação de acesso da aplicação.

Um acessório pode ter vários identificadores actor relevantes para fazer uma determinação de acesso. Da mesma forma, pode haver várias purposes ou environments relevantes em um contexto de consentimento específico. Portanto, todas as propriedades de acessório relevantes precisam ser fornecidas como parte de uma solicitação HTTP FHIR para representar corretamente esse acessório para fins de consentimento.

Por exemplo, o escopo de consentimento para uma determinada solicitação de dados pode ser o seguinte:

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

Isso representa uma enfermeira ou um médico conhecido como profissional 444, que é membro do grupo 999, que representa profissionais de um departamento em um hospital específico. O profissional está lá para fornecer tratamento regular, mas e talvez também precise de tratamento emergencial como parte dessas ações. O profissional está usando um aplicativo de software chamado abc.

O escopo de consentimento é fornecido como um Escopo de consentimento de solicitação como parte da solicitação de dados de um acessório.

Solicitar escopo de consentimento

As solicitações FHIR usam cabeçalhos de solicitação HTTP FHIR para receber o escopo de consentimento do acessor. Este escopo de consentimento contém um conjunto de actor, purpose e environment para refletir a identidade, as qualificações atuais do acessador intenção de uso e restrições ambientais nas quais o acessador opera. Pode haver mais de uma dessas propriedades que representam um escopo de consentimento do acessador a qualquer momento.

As entradas de escopo de consentimento são definidas da seguinte maneira:

  • actor/{type}/{ID}: uma propriedade actor em que o recurso type está fornecido junto com o ID. Exemplos de type incluem:

    • Practitioner
    • Group
    • Patient

    Por exemplo, se um armazenamento no formato projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID chamar a API, uma referência local a um ator Practitioner/123 será resolvida como projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.

  • purp/v3/{value}: uma propriedade purpose em que value é um membro do Objetivo de uso de FHIR (v3) ou a extensão dele. Exemplos de value incluem:

    • TREAT
    • ETREAT
    • HRESCH

  • env/{type}/{value}: uma propriedade environment em que type e value são strings personalizadas sem taxonomia predefinida. Exemplos de type e value incluem:

    • App/my_app_1
    • Net/VPN

Além disso, os cabeçalhos da solicitação HTTP FHIR também podem receber escopos especiais, como btg e bypass, que são definidos da seguinte maneira:

  • btg: o "break the glass" (ou BTG, na sigla em inglês) permite que você, como usuário humano, pule as verificações de consentimento em caso de emergências. Ele deve ser usado somente em emergências e é sujeito à revisão pós-auditoria. Como resultado, btg requer pelo menos um actor.
  • bypass: permite usuários confiáveis (como um administrador) ou usuários de confiança aplicativos (como um pipeline de treinamento de ML) para operar no repositório FHIR sem autorização. Portanto, bypass requer pelo menos um actor. e um env.
.

Aplicação e determinação do acesso

Em um ambiente de saúde complexo, em que várias políticas e consentimentos coexistem, aplicar o acesso e determinar as permissões de acesso pode ser uma tarefa assustadora. Várias partes interessadas podem ter expectativas e requisitos diferentes relacionadas ao uso e à divulgação de informações sobre pacientes. Para navegar nessa paisagem complexa, é necessário entender claramente como o acesso é aplicado e a lógica subjacente que governa a determinação do acesso.

Um consumidor da área da saúde, como um paciente ou um administrador, pode ter várias diretivas de consentimento contidas em um único recurso de consentimento. Os recursos de consentimento podem conter uma combinação de diretivas provision.type permit e deny. Por padrão, um usuário pode ter qualquer número de recursos de consentimento, mas para 200 active Os recursos de consentimento são aplicados por vez. Consulte Restrições e limitações para mais detalhes.

Todas as diretivas de consentimento são extraídas dos recursos de consentimento active de um determinado usuário para criar um conjunto de regras de consentimento agregadas.

A aplicação do consentimento é limitada a, no máximo, um propósito e a, no máximo, um ambiente por entrada de disposição.

As regras a seguir descrevem os princípios do controle de acesso conjunto de consentimento do paciente, políticas administrativas e políticas em cascata do administrador:

  • Por padrão, o acesso a todos os recursos é negado se não houver uma diretiva correspondente.

  • Se o recurso solicitado não existir, somente o tipo e o ID do recurso sejam identificáveis. Todos os outros critérios e o proprietário do recurso são desconhecido, a seguinte regra será aplicada na ordem de listagem:

    • Se o tipo de recurso pertencer ao compartimento de pacientes ou find-compartment: o acesso é negado.

    • Se esse não for seu caso, faça o seguinte:

      • Se houver uma política de administrador negando os critérios de acesso, independentemente dos outros critérios de recurso, o acesso será negado.

      • Se houver uma política de administrador que permita os critérios de acesso para os critérios de recurso identificável (ou seja, tipo e ID do recurso), um erro "recurso não encontrado" será retornado.

      • Em todos os outros casos, o acesso é negado.

  • As políticas de administrador são as políticas padrão usadas para corresponder recursos no armazenamento.

  • Os recursos que não pertencem a nenhum paciente são determinados apenas pelo administrador políticas.

  • Os recursos que estão no compartimento do paciente (STU3, R4) ou no compartimento de encontro (STU3, R4) precisam de pelo menos uma diretiva de consentimento de permissão por política de administrador ou do paciente ou política de administrador em cascata e nenhuma diretiva de consentimento de negação da política de administrador e do paciente e da política de administrador em cascata. Isso precisa de todos os pacientes indicados nos recursos a serem acessado pelo solicitante.

    • Alguns recursos podem ser usados por vários participantes. Por exemplo, Agendamento mostra uma lista de participantes que podem ser pacientes. Todos os pacientes nomeados nesses recursos precisam permitir o acesso ao acessório usando diretrizes de consentimento. Caso contrário, os recursos não serão retornados. Se um recurso tiver uma permissão de uma política de hierarquia de encontros, em que esse encontro referencia um paciente pelo campo subject (STU3, R4), o recurso será considerado permitido pelo paciente.

As regras descritas são resumidas pelo seguinte pseudocódigo:

Controle de acesso 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

O repositório FHIR verifica a permissão de consentimento por recurso. Qualquer referência em um recurso não é resolvida e cascadeada para fins de verificação de acesso de consentimento. Por exemplo, considere um paciente identificado por Patient/f001 que permite que um profissional de saúde acesse todo o recurso MedicationRequest, mas não o recurso Patient/f001 devido à privacidade do paciente. Nesse cenário, O profissional pode conferir todo o recurso MedicationRequest, o que inclui uma subject referente ao recurso Patient/f001, mas não é possível ver o o conteúdo do recurso Patient/f001, mesmo, por exemplo, ao executar uma pesquisa FHIR usando _include.

Resolução de conflitos

São possíveis conflitos entre várias diretivas permit e deny. Se duas diretivas conflitantes corresponderem a um recurso, o conflito será resolvido usando o modelo deny vence permit.

Apenas active consentimentos estão incluídos para a aplicação obrigatória.

Lógica de aplicação do acesso a recursos

Ao fazer uma solicitação com consentimento para um armazenamento FHIR, o controle de acesso ocorre na seguinte ordem:

  1. A API Cloud Healthcare verifica as permissões no Google Cloud conta de serviço (ou o principal) configurada no proxy. Se o serviço tem as permissões de IAM corretas para executar o método FHIR solicitado no armazenamento FHIR, a solicitação continua.

  2. Se a aplicação de consentimento estiver ativada na configuração do armazenamento FHIR e os cabeçalhos HTTP de consentimento estiverem presentes, a API Cloud Healthcare vai aplicar as políticas de acesso de consentimento para recursos de compartimento de pacientes. A aplicação das políticas de acesso de consentimento é baseada nos escopos de consentimento fornecidos na solicitação, de acordo com as diretivas de consentimento capturadas pela execução mais recente de ApplyConsents e ApplyAdminConsents.

As regras a seguir se aplicam ao fazer uma solicitação com consentimento para um armazenamento FHIR:

  • Forneça pelo menos um escopo de consentimento actor relevante para as ações de consentimento realizadas.

  • Forneça outros escopos purpose e environment relevantes para as ações de consentimento realizadas.

  • Se o número de entradas de escopo de consentimento exceder o limites compatíveis, será retornado um erro.

  • Se você chamar um método que acessa vários recursos (por exemplo, o fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle, ou fhir.search a aplicação do consentimento se aplica a cada recurso individual. No entanto, há uma pequena diferença entre esses métodos de acesso a vários recursos:

    • fhir.executeBundle lendo vários recursos recebe "Acesso de consentimento negado ou o recurso que está sendo acessado não existe" para recursos individuais sem permissões de consentimento (consulte exemplos no Receber recursos FHIR com escopo de consentimento).

    • O fhir.search pula recursos sem permissões de consentimento e não retorna erro de acesso negado, mesmo para pesquisa por _id (veja exemplos na Pesquisar recursos FHIR com escopo de consentimento).

    • fhir.Patient-everything e fhir.Encounter-everything se comportam de maneira semelhante para fhir.search, com a exceção de retornar "Acesso de consentimento negado ou o recurso acessado não existe se o autor da chamada não tiver consentimento permissão no recurso Paciente ou Encounter solicitado, respectivamente.

Uma diretiva de consentimento tem no máximo um actor, no máximo um purpose e no máximo um environment, enquanto o escopo de consentimento pode ter vários de cada um. Pouco consentimento não especificam as três propriedades do acessador. Nesse caso, o valor da propriedade do escopo de consentimento pode corresponder dependendo regras de resolução de conflitos. Como resultado, um escopo de consentimento pode corresponder a mais de uma diretiva de consentimento.

Se o escopo de consentimento de uma solicitação incluir duas ou mais entradas do mesmo tipo de escopo de consentimento (actor, purpose ou environment), o escopo de consentimento provavelmente corresponde a várias diretrizes de consentimento. Algumas diretivas de consentimento não especificam purpose ou environment. Portanto, o escopo do consentimento também precisa ser correspondido a diretivas de consentimento que não especificam esses tipos de escopo.

Por exemplo, definir o escopo de consentimento como actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc corresponde a qualquer uma das diretivas de consentimento permit ou deny a seguir:

  • 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

A seguir