Modelo de dados de acesso FHIR e sistema de controle

Informações gerais do modelo de dados

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

As regras de acesso são expressas por recursos de consentimento FHIR. O consentimento FHIR é um tipo de recurso FHIR que captura as escolhas de um consumidor de saúde. Ela permite ou nega um conjunto de atores para executar ações que afetam o consumidor para uma finalidade específica de um ambiente especificado durante um período. Por exemplo, um consumidor pode ser um paciente de saúde, qualquer pessoa que atue em nome de um paciente ou outra pessoa que assine um contrato de consentimento.

As ações registradas em um consentimento de 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á em ações relacionadas ao acesso a dados, e a aplicação dessas ações está limitada à leitura de dados de FHIR de um armazenamento de FHIR.

Um recurso de consentimento tem um status que indica o estado atual do consentimento. Um armazenamento FHIR pode conter muitos consentimentos em estados diferentes, mas a API Cloud Healthcare aplica somente consentimentos que estejam no estado ativo. Consentimentos em qualquer outro estado não têm efeito na aplicação. Se um consentimento é dado em nome de um paciente, ele é registrado como dado 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 o máximo de dados definido pelo compartimento do paciente (STU3, R4).

  • Política de administração: 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 no armazenamento especificado pelos critérios de recursos. A política de administração define a política padrão para todos os recursos de vinculação no armazenamento.

  • Política em cascata de administrador: um tipo de política de administrador que exige 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 correspondam aos critérios de recursos. Tem as seguintes limitações:

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

As diretivas de consentimento são instruções codificadas em um consentimento do FHIR que permitem ou negam o acesso a dados de uma entidade autorizada, como um beneficiário ou um acessador. Um único consentimento 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 abrangidas por esta diretiva. Somente access é compatível para fornecer acesso somente leitura.

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

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

Critérios do acessador

A API Cloud Healthcare oferece suporte para três propriedades de um acessador para uso dentro de uma diretiva de consentimento e para corresponder a um acessador que faz uma solicitação de acesso a dados. É necessário que haja uma correspondência exata com diferenciação de maiúsculas e minúsculas para que uma diretiva seja aplicada ao acessador 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 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 acessador está agindo.

Por exemplo, um acessador pode ser representado pelas seguintes propriedades:

  • Agente: Practitioner/123

  • Objetivo: ETREAT ou acesso para tratamentos de emergência

  • Ambiente: Application/abc

Neste exemplo, essas propriedades representam um médico que acessa 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. Não é possível resolver esse link.

Todas as diretivas de consentimento precisam especificar um actor para serem aplicadas, mas nem sempre precisam especificar uma purpose ou um environment. Por exemplo, se nenhum environment for especificado na diretiva de consentimento, ela vai corresponder a qualquer environment que ainda 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 a que a política de consentimento se vincula, por exemplo, Encounter, Observation ou Immunization.

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

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

  • Tag de dados: representa o rótulo personalizado do recurso, conforme descrito no 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). Os sistemas de código a seguir têm suporte:

    • Confidencialidade: valores hierárquicos classificados de irrestritos a mais restritos: 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 marcador de segurança R, ele será aplicado a todos os recursos que são pelo menos tão confidenciais quanto R.

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

Fluxo de trabalho de acesso

authorization_flow

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

Ao fazer uma solicitação de acesso a dados, um acessador opera dentro de um escopo de consentimento específico que representa as propriedades actor, purpose e environment relacionadas a qualquer solicitação HTTP FHIR. Os valores dessas propriedades precisam diferenciar maiúsculas de minúsculas e os dados fornecidos com um consentimento para que afetem a determinação de acesso da aplicação.

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

Por exemplo, o escopo de consentimento de 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

Representa um enfermeiro ou um médico conhecido como 444 que é membro do grupo 999, que representa profissionais de um departamento dentro de um hospital específico. O profissional está lá para fornecer tratamento regular, mas também pode lidar com o tratamento de emergência como parte dessas ações. O profissional está usando um aplicativo de software chamado abc.

O escopo de consentimento é oferecido como um escopo de solicitação de consentimento como parte da solicitação de dados de um acessador.

Escopo da solicitação de consentimento

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

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

  • actor/{type}/{ID}: uma propriedade actor em que o recurso type é fornecido com o ID. Confira alguns exemplos de type:

    • Practitioner
    • Group
    • Patient

    Por exemplo, se um armazenamento 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 do Objetivo de uso FHIR (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 FHIR também podem receber escopos especiais, como btg e bypass, definidos da seguinte maneira:

  • btg: o acesso imediato (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 à revisão pós-auditoria. Como resultado, btg requer 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 no armazenamento FHIR sem autorização de consentimento. Portanto, bypass requer pelo menos um actor e um env.

Aplicação e determinação de acesso

Em um ambiente de saúde complexo, em que várias políticas e consentimentos coexistem, impor 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 dos pacientes. Navegar por esse cenário complexo requer uma compreensão clara de como o acesso é aplicado e da 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 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 recursos de consentimento são aplicados de uma vez. Consulte Restrições e limitações para mais detalhes.

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

A aplicação de consentimento é limitada a, no máximo, uma finalidade e no máximo um ambiente por entrada de provisionamento.

As regras a seguir descrevem os princípios para o controle de acesso conjunto do consentimento do paciente e da política administrativa em cascata do administrador:

  • Por padrão, todos os recursos terão acesso 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 e o proprietário do recurso são desconhecidos. A regra a seguir se aplica ao pedido de listagem:

    • Se o tipo de recurso pertencer ao compartimento do paciente ou ao compartimento: o acesso será negado.

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

      • Se houver uma política de administrador que negue os critérios do acessador, independentemente dos outros critérios do 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áveis (ou seja, tipo e ID do recurso), um erro "recurso não encontrado" será retornado.

      • Em todos os outros casos, o acesso será negado.

  • Políticas administrativas são as políticas padrão usadas para corresponder recursos no armazenamento.

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

  • Os recursos que estão no compartimento do paciente (STU3, R4) ou encontram o compartimento (STU3, R4) precisam de pelo menos uma diretiva de permissão de consentimento por paciente ou política de administrador ou política em cascata do administrador e diretiva de não negação de consentimento da política de administrador e de administração e de política de cascata do administrador. Essa condição é necessária para todos os pacientes indicados nos recursos a serem acessados pelo solicitante.

    • Alguns recursos podem ter vários pacientes. Por exemplo, Consulta fornece uma lista de participantes, que podem ser pacientes. Todos os pacientes nomeados nesses recursos precisam permitir o acesso ao acessador usando diretivas de consentimento. Caso contrário, os recursos não serão retornados. Se um recurso tiver uma permissão de uma política de cascata de encontro em que esse encontro se referir a um paciente no campo subject (STU3, R4), o recurso será considerado permitido pelo paciente.

As regras descritas são resumidas neste 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 por recurso. As referências em um recurso não são resolvidas e aplicadas em cascata para fins da verificação do acesso de consentimento. Por exemplo, considere um paciente identificado por Patient/f001, que permite que um profissional acesse todo o recurso MedicationRequest, mas não o Patient/f001 em si, devido à privacidade do paciente. Nesse cenário, o profissional pode ver todo o recurso MedicationRequest, que inclui um campo subject referente ao recurso Patient/f001, mas não pode ver o conteúdo do recurso Patient/f001, mesmo, por exemplo, ao realizar uma pesquisa FHIR usando _include.

Resolução de conflitos

É possível haver 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 sobre permit.

Apenas active consentimentos estão incluídos para a aplicação de consentimento.

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

Ao fazer uma solicitação de 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 do IAM corretas para executar o método FHIR solicitado no armazenamento FHIR, a solicitação continuará.

  2. Se a aplicação do consentimento estiver ativada na configuração do repositório FHIR e os cabeçalhos HTTP com reconhecimento de consentimento estiverem presentes, a API Cloud Healthcare aplicará políticas de acesso de consentimento aos recursos do compartimento de pacientes. A aplicação das políticas de acesso de consentimento se baseia 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 reconhecimento de consentimento para um armazenamento FHIR:

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

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

  • Quando o número de entradas do escopo de consentimento excede os limites compatíveis, um erro é retornado.

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

    • Ao ler vários recursos, fhir.executeBundle recebe a mensagem "Acesso de consentimento negado ou o recurso que está sendo acessado não existe" para recurso individual sem permissões de consentimento. Confira exemplos em Acessar recursos FHIR com escopo de consentimento.

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

    • fhir.Patient-everything se comporta de maneira semelhante a fhir.search, exceto por retornar "Acesso de consentimento 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 solicitado.

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. Algumas diretivas de consentimento não especificam as três propriedades de acesso. Nesse caso, qualquer valor de propriedade do escopo de consentimento pode corresponder, dependendo das regras de resolução de conflitos. Consequentemente, 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 (actor, purpose ou environment), ele poderá corresponder a várias diretivas de consentimento. Algumas diretivas de consentimento não especificam um purpose ou um environment. Portanto, o escopo de consentimento também precisa corresponder às 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 destas diretivas de consentimento permit ou 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

A seguir