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 que se aplicam e a quais dados elas se aplicam.

As regras de acesso são expressas por meio de recursos de consentimento de FHIR. O consentimento de FHIR é um tipo de recurso FHIR que captura as escolhas do consumidor do serviço da saúde. Ela permite ou nega que um conjunto de atores execute ações que afetam o consumidor para um finalidade específico 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 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 do que apenas os dados de registro eletrônico de saúde (EHR, na sigla em inglês) do consumidor. No entanto, para os 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 FHIR de um armazenamento FHIR.

O recurso de consentimento tem um status que indica o estado atual dele. Um armazenamento FHIR pode conter muitos consentimentos em estados diferentes, mas a API Cloud Healthcare só impõe consentimentos que estão no estado ativo. Consentimentos em qualquer outro estado não afetam a aplicação. Se um consentimento é dado em nome de um paciente, a autorização é registrada como "concedida" 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 usando Consent.patient (STU3, R4) e vincula o máximo de dados definido pelo compartimento do paciente (STU3, R4).

  • Política do 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 no armazenamento especificado pelos critérios de recursos. A política do administrador 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 do recurso. Ele tem as seguintes limitações:

    • Oferece suporte apenas para Paciente (STU3, R4) ou Encounter (STU3, R4) como base de compartimento.
    • O armazenamento de 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 acesso a um recurso. Na falta do consentimento de um paciente, a política administrativa pode aprovar o acesso a um recurso.

As diretivas de consentimento são instruções codificadas em um consentimento FHIR que permitem ou negam o acesso aos dados para uma entidade autorizada, como um beneficiário ou um assistente de acesso. 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 do acesso: um conjunto de atributos que identificam o solicitante da API coberto pela diretiva.

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

Critérios de acesso

A API Cloud Healthcare é compatível com três propriedades de um acessador para uso dentro de uma diretiva de consentimento e para corresponder a um acessador que faça uma solicitação de acesso a dados. É preciso que haja uma correspondência exata que diferencia maiúsculas de 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 forma:

  • Ator: representa um papel individual, grupo ou 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

  • Finalidade: ETREAT ou acesso para fins de tratamento emergencial

  • Ambiente: Application/abc

Neste 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 (ambos em inglês). Observe que essa vinculação não pode ser resolvida.

Todas as diretivas de consentimento precisam especificar um actor para ser aplicado, mas nem sempre precisam especificar um purpose ou um environment. Por exemplo, se nenhum environment for especificado na diretiva de consentimento, ela corresponderá a qualquer environment que ainda não tenha sido 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 a que a política de consentimento se vincula.

  • Fonte de dados: representa a origem do recurso conforme identificado pelo recurso meta.source (disponível apenas na 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). 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, 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 forem pelo menos tão sensíveis quanto R.

    • ActCode: correspondência exata de string 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 acessador opera em um determinado escopo de consentimento que representa as propriedades actor, purpose e environment relacionadas a qualquer solicitação HTTP FHIR. Os valores dessas propriedades precisam corresponder a maiúsculas e minúsculas àqueles fornecidos com o 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 do 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 do 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 um enfermeiro ou 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 possivelmente também 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 solicitação de consentimento como parte da solicitação de dados de um acessador.

Solicitar escopo 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 atuais do acessador em que ele opera. Pode haver mais de uma dessas propriedades que representem o escopo de consentimento de um acessador ao mesmo tempo.

As entradas do 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 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 é membro do conjunto de valores de Finalidade de uso de FHIR (v3) ou a extensão correspondente. Exemplos de value:

    • 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 (BTG) 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 à análise 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 do acesso

Em um ambiente de saúde complexo, em que várias políticas e consentimentos coexistem, impor acesso e determinar 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 de 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 controla a determinação do acesso.

Um consumidor de serviços de 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 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 do 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 uma finalidade e no máximo um ambiente por entrada de disposição.

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

  • Se não houver uma diretiva correspondente, o acesso a todos os recursos será negado por padrão.

  • 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 na ordem de listagem:

    • Se o tipo de recurso pertencer ao compartimento de pacientes ou de encontro: 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.

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

  • Recursos que não pertencem a nenhum paciente são determinados apenas pelas políticas do administrador.

  • Os recursos que estão no compartimento de pacientes (STU3, R4) ou que encontram compartimentos (STU3, R4) precisam de pelo menos uma diretiva de permissão de permissão por paciente ou política de administrador ou política em cascata do administrador ou política de consentimento de não negação do paciente e política admin e a política em cascata do administrador. Essa condição é necessária para que todos os pacientes nomeados nos recursos sejam 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 nesses recursos precisam permitir o acesso ao acessador usando diretivas de consentimento. Caso contrário, os recursos não são retornados. Se um recurso tiver uma permissão de uma política em cascata de encontro, em que o encontro se referir a um paciente no 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 de FHIR verifica a permissão de consentimento por recurso. As referências em um recurso não são resolvidas e ficam em cascata para fins de verificação de 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 recurso 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 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 reconhecimento 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 de IAM corretas para executar o método FHIR solicitado no armazenamento FHIR, a solicitação prosseguirá.

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

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

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

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

  • Se você chamar um método que acessa vários recursos (por exemplo, o método 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 a vários recursos:

    • O fhir.executeBundle que lê 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. Confira exemplos em Receber 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.

    • O fhir.Patient-everything se comporta de maneira semelhante a fhir.search, mas retorna "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, um purpose e no máximo um environment. O escopo do consentimento pode ter vários de cada. Algumas diretivas de consentimento não especificam as três propriedades do acessador. 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 (actor, purpose ou environment), ele poderá corresponder a várias diretivas de consentimento. Algumas diretivas de consentimento não especificam purpose ou environment. Portanto, o escopo do 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