Modelo de dados de acesso e sistema de controle do FHIR

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 nos recursos de consentimento do FHIR. O consentimento do FHIR é um tipo de recurso do FHIR que captura as escolhas de um consumidor de saúde. Ele permite ou nega que um conjunto de atores realizem ações que afetam o consumidor para um propósito específico em um ambiente especificado por um período. Por exemplo, um consumidor pode ser um paciente de saúde, qualquer pessoa que atue em nome de um paciente de saúde ou outra pessoa que celebra um contrato de consentimento.

As ações registradas em um consentimento do FHIR podem ser amplas e lidar com mais do que apenas os dados do registro de saúde eletrônico (EHR, na sigla em inglês) do consumidor. No entanto, para fins de consentimento na API Cloud Healthcare, o foco está nas ações relacionadas ao acesso a dados, e a aplicação dessas ações é limitada à leitura de dados do FHIR de um armazenamento do FHIR.

Um recurso de consentimento tem um status que indica o estado atual do consentimento. Embora um armazenamento FHIR possa conter muitos consentimentos em estados diferentes, a API Cloud Healthcare só aplica consentimentos que estão no estado ativo. Os consentimentos em qualquer outro estado não têm efeito na aplicação. Se o consentimento for dado em nome de um paciente, ele será registrado como concedido por um artista.

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 usando Consent.patient (STU3, R4) e vincula tantos dados quantos 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. Esse tipo de política pode ser vinculado a um subconjunto ou a todos os recursos na loja especificados pelos critérios de recursos. A política de administrador define a política padrão para todos os recursos de vinculação na loja.

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

    • Suporte apenas para paciente (STU3, R4) ou encontro (STU3, R4) como base do 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 do FHIR que permite ou nega o acesso a dados a uma entidade autorizada, como um beneficiário ou um acessor. Um único consentimento do FHIR pode codificar várias diretivas de consentimento. Cada diretiva fornece o seguinte:

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

  • Ação: as permissões cobertas por essa diretiva. Somente access é aceito para fornecer 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 acessório

A API Cloud Healthcare oferece suporte a três propriedades de um acionador para uso em uma diretiva de consentimento e para corresponder a um acionador que faz uma solicitação de acesso a dados. É 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 maneira:

  • Ator: representa um indivíduo, grupo ou papel de acesso que identifica o acessório 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

  • Finalidade: ETREAT ou acesso para fins de tratamento de emergência

  • 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 pode ser resolvido.

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 meta.tag do recurso (STU3, R4).

  • Rótulo de segurança: representa rótulos de segurança que definem os recursos afetados como identificados no campo meta.security (STU3, R4). Os seguintes sistemas de código são aceitos:

    • Confidencialidade: valores hierárquicos classificados de não restrito a mais restrito: U, L, M, N, R, V. Se um consentimento permitir um rótulo de segurança de R, ele será aplicado a todos os recursos rotulados como R ou inferior. 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

Esta figura ilustra a jornada completa de uma solicitação para uma loja com controle de acesso do FHIR. Um token externo com o escopo de consentimento (à esquerda) é usado pelo aplicativo (#3) ao fazer uma solicitação para a loja 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 precisam corresponder aos fornecidos em um consentimento, com distinção entre maiúsculas e minúsculas, 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 também pode lidar com tratamento de emergência 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. Esse escopo de consentimento contém um conjunto de valores actor, purpose e environment para refletir a identidade atual do acessório, as qualificações, a intenção de uso e as restrições ambientais em que o acessório opera. Pode haver mais de uma dessas propriedades que representam o escopo de consentimento de um accessor 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 é fornecido com o ID. Exemplos de type incluem:

    • Practitioner
    • Group
    • Patient

    Por exemplo, se uma loja do 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 é membro do conjunto de valores FHIR Purpose of Use (v3) ou da 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 de solicitação HTTP do 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 apenas em emergências e está sujeito a uma análise pós-auditoria. Como resultado, btg exige pelo menos um actor.
  • bypass: permite que usuários confiáveis (como um administrador) ou aplicativos confiáveis (como um pipeline de treinamento de ML) operem na loja FHIR sem autorização de consentimento. 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 em relação ao uso e à divulgação das informações do paciente. 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 de cuidados de saúde, como um paciente ou um administrador, pode ter várias diretivas de consentimento 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 até 200 active 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 para o controle de acesso conjunto de consentimento do paciente, política de administrador e política 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, apenas o tipo e o ID do recurso serão identificáveis. Todos os outros critérios de recurso e o proprietário do recurso são desconhecidos. A regra a seguir se aplica na ordem de listagem:

    • Se o tipo de recurso pertencer ao compartimento do paciente ou ao compartimento de atendimento, o acesso será 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 a recursos na loja.

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

  • 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. Essa condição é necessária para que todos os pacientes nomeados nos recursos sejam acessados 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 o 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 armazenamento FHIR verifica a permissão de consentimento no nível de cada 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 ver todo o recurso MedicationRequest, que inclui um campo subject que se refere ao recurso Patient/f001, mas não pode acessar o conteúdo do recurso Patient/f001, mesmo, por exemplo, ao realizar uma pesquisa FHIR usando _include.

Resolução de conflitos

É possível que haja 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 os consentimentos active são incluídos para a aplicação do consentimento.

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 na conta de serviço do Google Cloud (ou no principal) configurada no proxy. Se a conta de serviço tiver as permissões corretas do IAM para executar o método FHIR solicitado na loja FHIR, a solicitação vai prosseguir.

  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 os limites compatíveis, um erro será retornado.

  • Se você chamar um método que acesse vários recursos (por exemplo, os métodos 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 diferença sutil 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).

    • fhir.search pula recursos sem permissões de consentimento e não retorna o erro de acesso negado de consentimento, mesmo para pesquisar por _id. Consulte exemplos no Pesquisar recursos FHIR com escopo de consentimento.

    • fhir.Patient-everything e fhir.Encounter-everything se comportam de maneira semelhante a fhir.search, exceto que eles retornam "O consentimento de acesso foi negado ou o recurso que está sendo acessado não existe" se o autor da chamada não tiver permissão de consentimento no recurso de paciente ou de encontro 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. Algumas diretivas de consentimento não especificam as três propriedades de acessório. Nesse caso, qualquer valor de propriedade do escopo de consentimento pode corresponder, dependendo das 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 diretrizes de consentimento não especificam um purpose ou um 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