Modelo de dados de acesso FHIR e sistema de controlo

Esta página descreve como usar o sistema de controlo de acesso FHIR da Cloud Healthcare API para gerir e proteger os seus dados de cuidados de saúde. Pode usar o controlo de acesso FHIR para definir políticas de consentimento, controlar o acesso aos dados com base nas funções do utilizador e no contexto, e aplicar estas políticas numa loja FHIR.

Vista geral do modelo de dados

O modelo de dados para o controlo de acesso é representado por recursos de consentimento. Definem as regras que se aplicam e a que dados as regras se aplicam.

As regras de acesso são expressas através de recursos FHIR Consent. O consentimento FHIR é um tipo de recurso FHIR que capta as escolhas de um consumidor de cuidados de saúde. Permite ou nega a um conjunto de atores a realização de ações que afetam o consumidor para um objetivo específico a partir de um ambiente especificado durante um período. Por exemplo, um consumidor pode ser um paciente de cuidados de saúde, qualquer pessoa que atue em nome de um paciente de cuidados de saúde ou outro indivíduo que celebre um contrato de consentimento.

As ações registadas num consentimento FHIR podem ser amplas e abranger mais do que apenas os dados do registo de saúde eletrónico (RSE) do consumidor. No entanto, para efeitos de consentimento na Cloud Healthcare API, o foco está nas ações relacionadas com o acesso aos dados, e a aplicação dessas ações limita-se à leitura de dados FHIR a partir de um arquivo FHIR.

Um recurso Consent tem um status que indica o estado atual do consentimento. Embora um arquivo FHIR possa conter muitos consentimentos em diferentes estados, a Cloud Healthcare API apenas aplica consentimentos que se encontram no estado ativo. Os consentimentos noutros estados não têm efeito na aplicação. Se for dado um consentimento em nome de um paciente, o consentimento é registado como tendo sido concedido por um artista.

Tipo de política

A Cloud Healthcare API suporta os seguintes tipos de políticas de consentimento:

  • Consentimento do paciente: está associado a um paciente que usa Consent.patient (STU3, R4) e associa tantos dados quanto definidos pelo compartimento do paciente (STU3, R4).

  • Política de administrador: não está associada a nenhum paciente e tem de ter um URL de extensão https://g.co/fhir/medicalrecords/ConsentAdminPolicy. Este tipo de política pode ser associado a um subconjunto ou a todos os recursos na loja especificada pelos critérios de recursos. A política de administrador define a política predefinida para todos os recursos de associação na loja.

  • Política em cascata de administrador: um tipo de política de administrador que requer o URL da extensão https://g.co/fhir/medicalrecords/CascadingPolicy e o URL da extensão da política de administrador. Pode associar este tipo de política a um compartimento de recursos que correspondem aos critérios de recursos. Tem as seguintes limitações:

Pode combinar tipos de políticas ao mesmo nível de recurso para permitir ou recusar o acesso a um recurso. Se o consentimento de um paciente estiver em falta, a política de administrador pode aprovar o acesso a um recurso.

As diretivas de consentimento são instruções codificadas num consentimento FHIR que permitem ou negam o acesso aos dados a uma entidade autorizada, como um concessionário ou um acessor. 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 autorizações abrangidas por esta diretiva. Apenas access é suportado para fornecer acesso só de leitura.

  • Critérios do acessor: um conjunto de atributos que identificam o requerente da API abrangido pela diretiva.

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

Critérios de acessório

A Cloud Healthcare API suporta três propriedades de um acessor para utilização numa diretiva de consentimento e para correspondência com um acessor que faça um pedido de acesso aos dados. Tem de existir uma correspondência exata sensível a maiúsculas e minúsculas para que uma diretiva seja aplicada no acesso como parte da determinação do acesso oferecida pelo servidor FHIR.

Estas propriedades são codificadas da seguinte forma:

  • Ator: representa um indivíduo, um grupo ou uma função de acesso que identifica o autor do acesso ou uma característica do autor do acesso.

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

  • Ambiente: representa um identificador abstrato que descreve o ambiente ou as condições sob as quais o acessor está a agir.

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

  • Ator: Practitioner/123

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

  • Ambiente: Application/abc

Neste exemplo, estas propriedades representam um médico que está a aceder a dados quando realiza um tratamento de emergência através de uma aplicação de software denominada abc.

provision.actor e provision.purpose são definidos como parte da norma FHIR, enquanto o ambiente é https://g.co/fhir/medicalrecords/Environment. Tenha em atenção que este link não é resolvível.

Todas as diretivas de consentimento têm de especificar um actor a ser aplicado, mas não têm de especificar sempre um purpose ou um environment. Por exemplo, se não for especificado nenhum environment na diretiva de consentimento, a diretiva corresponde a qualquer environment que ainda não esteja abrangido por outras diretivas de consentimento.

Critérios de recursos

A API Cloud Healthcare suporta os seguintes elementos como parte do recurso de consentimento:

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

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

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

  • Etiqueta de dados: representa a etiqueta personalizada do recurso, conforme descrito no recurso meta.tag (STU3, R4).

  • Etiqueta de segurança: representa etiquetas de segurança que definem os recursos afetados, conforme identificado no campo meta.security (STU3 e R4). Os seguintes sistemas de códigos são suportados:

    • Confidencialidade: valores hierárquicos classificados do menos restrito para o mais restrito: U, L, M, N, R, V. Se um consentimento permitir uma etiqueta de segurança de R então aplica-se a todos os recursos etiquetados como R ou inferior. Se um consentimento recusar uma etiqueta de segurança R, aplica-se a todos os recursos que sejam, pelo menos, tão sensíveis quanto R.

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

Fluxo de trabalho de acesso

authorization_flow

Esta figura ilustra o percurso completo de um pedido a uma loja com controlo de acesso FHIR ativado. Um token externo com o âmbito de consentimento (à esquerda) é usado pela aplicação n.º 3 quando faz um pedido à loja FHIR com o controlo de acesso ativado (à direita).

Quando faz um pedido de acesso a dados, um acessor opera num determinado âmbito de consentimento que representa as respetivas propriedades actor, purpose e environment relacionadas com qualquer pedido HTTP FHIR. Os valores destas propriedades têm de corresponder exatamente às maiúsculas e minúsculas dos valores fornecidos num consentimento para afetarem a determinação do acesso da aplicação.

Um acessor pode ter vários identificadores actor relevantes para tomar uma determinação de acesso. Da mesma forma, podem existir vários purposes ou environments relevantes num contexto de consentimento específico. Por conseguinte, todas as propriedades de acesso relevantes devem ser fornecidas como parte de um pedido HTTP FHIR para representar corretamente esse acessor para fins de consentimento.

Por exemplo, o âmbito do consentimento para um determinado pedido de dados pode ser o seguinte:

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

Isto representa um enfermeiro ou um médico conhecido como profissional de saúde 444 que é membro do grupo 999, que representa profissionais de saúde de um departamento num hospital específico. O profissional está presente para fornecer tratamento regular, mas também pode lidar com tratamentos de emergência como parte destas ações. O profissional está a usar uma aplicação de software denominada abc.

O âmbito do consentimento é fornecido como um âmbito do consentimento do pedido como parte do pedido de dados de um acessor.

Solicite o âmbito do consentimento

Os pedidos FHIR usam cabeçalhos de pedidos HTTP FHIR para receber o âmbito de consentimento do acessor. Este âmbito de consentimento contém um conjunto de valores actor, purpose e environment para refletir a identidade atual, as qualificações, a intenção de utilização e as restrições ambientais em que o acessor opera. Pode haver mais do que uma de cada uma destas propriedades que representam o âmbito do consentimento de um acessor em qualquer altura.

As entradas do âmbito do consentimento de consentimento são definidas da seguinte forma:

  • actor/{type}/{ID}: uma propriedade actor onde o recurso type é fornecido juntamente com o ID. Seguem-se alguns exemplos de type:

    • 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 é 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 respetiva extensão. Exemplos de value:

    • TREAT
    • ETREAT
    • HRESCH

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

    • App/my_app_1
    • Net/VPN

Além disso, os cabeçalhos de pedidos HTTP FHIR também podem receber âmbitos especiais, como btg e bypass, que são definidos da seguinte forma:

  • btg: o acesso a plano de último recurso (ou BTG) permite-lhe, como utilizador humano, ignorar as verificações de consentimento em caso de emergências. Deve ser usado apenas em emergências e está sujeito a revisão pós-auditoria. Como resultado, btg requer, pelo menos, um actor.
  • bypass: permite que utilizadores fidedignos (como um administrador) ou aplicações fidedignas (como um pipeline de preparação de ML) operem na loja FHIR sem autorização de consentimento. Por conseguinte, bypass requer, pelo menos, um actor e um env.

Aplicação e determinação do acesso

Num ambiente de cuidados de saúde complexo onde coexistem várias políticas e consentimentos, a aplicação do acesso e a determinação das autorizações de acesso podem ser uma tarefa difícil. Vários intervenientes podem ter diferentes expetativas e requisitos relativamente à utilização e divulgação de informações dos pacientes. Navegar neste cenário complexo requer uma compreensão clara de como o acesso é aplicado e da lógica subjacente que rege 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 contidas num único recurso de consentimento. Os recursos de consentimento podem conter uma combinação de diretivas permit e deny provision.type. Por predefinição, um utilizador pode ter qualquer número de recursos Consentimento, mas são aplicados até 200 recursos Consentimento active de cada vez. Consulte a secção Restrições e limitações para ver mais detalhes.

Todas as diretivas de consentimento são extraídas dos activerecursos de consentimento para um determinado utilizador, de modo a criar um conjunto de regras de consentimento agregadas.

A aplicação da autorização é limitada a, no máximo, um objetivo e, no máximo, um ambiente por entrada de fornecimento.

As regras seguintes descrevem os princípios do controlo de acesso conjunto do consentimento do paciente, da política de administrador e da política de administrador em cascata:

  • Por predefinição, o acesso a todos os recursos é recusado se não existir uma diretiva correspondente.

  • Se o recurso pedido não existir, apenas o tipo de recurso e o ID do recurso são identificáveis. Se todos os outros critérios de recursos e o proprietário do recurso forem desconhecidos, aplica-se a seguinte regra na ordem da ficha:

    • Se o tipo de recurso pertencer ao patient-compartment ou encounter-compartment: o acesso é recusado.

    • Caso contrário:

      • Se existir uma política de administrador que negue os critérios do acessor independentemente dos outros critérios de recursos, o acesso é negado.

      • Se existir uma política de administrador que permita os critérios do acessor para os critérios de recursos identificáveis (ou seja, tipo de recurso e ID do recurso), é devolvido um erro "recurso não encontrado".

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

  • As políticas de administrador são as políticas predefinidas usadas para fazer corresponder recursos na loja.

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

  • Os recursos que se encontram no compartimento do paciente (STU3, R4) ou no compartimento do encontro (STU3, R4) precisam de, pelo menos, uma diretiva de consentimento de autorização por paciente ou política de administrador ou política de administrador em cascata e nenhuma diretiva de consentimento de recusa do paciente e política de administrador e política de administrador em cascata. Esta condição é necessária para que o requerente aceda a todos os pacientes indicados nos recursos.

    • Alguns recursos podem suportar vários participantes pacientes. Por exemplo, o tipo de dados Compromisso fornece uma lista de participantes, que podem ser pacientes. Todos os pacientes mencionados nesses recursos têm de permitir o acesso ao acesso através de diretivas de consentimento. Caso contrário, os recursos não são devolvidos. Se um recurso tiver uma autorização de uma política em cascata de um encontro, em que este encontro faz referência a um paciente através do campo subject (STU3, R4), o recurso é considerado permitido pelo paciente.

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

Controlo 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 FHIR store verifica a autorização de consentimento ao nível de cada recurso. Qualquer referência num recurso não é resolvida nem em cascata para fins de verificação do acesso ao consentimento. Por exemplo, considere um paciente identificado por Patient/f001 que permite que um profissional de saúde aceda a todo o recurso MedicationRequest, mas não ao próprio recurso Patient/f001 devido à privacidade do paciente. Neste cenário, o profissional de saúde pode ver o recurso MedicationRequest completo, que inclui um campo subject que faz referência ao recurso Patient/f001, mas não pode ver o conteúdo do recurso Patient/f001, mesmo, por exemplo, quando realiza uma pesquisa FHIR com _include.

Resolução de conflitos

É possível haver conflitos entre várias diretivas permit e deny. Se duas diretivas em conflito corresponderem a um recurso, o conflito é resolvido através do modelo deny tem prioridade sobre permit.

Apenas os consentimentos active são incluídos para a aplicação do consentimento.

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

Quando faz um pedido com reconhecimento de consentimento a um arquivo FHIR, o controlo de acesso ocorre pela seguinte ordem:

  1. A API Cloud Healthcare verifica as autorizações na Google Cloud conta de serviço (ou no principal) configurada no proxy. Se a conta de serviço tiver as autorizações de IAM corretas para executar o método FHIR pedido na loja FHIR, o pedido prossegue.

  2. Se a aplicação da política de consentimento estiver ativada na configuração do FHIR store e os cabeçalhos HTTP com reconhecimento de consentimento estiverem presentes, a Cloud Healthcare API aplica as políticas de acesso de consentimento aos recursos Patient Compartment. A aplicação das políticas de acesso ao consentimento baseia-se nos âmbitos de consentimento fornecidos no pedido, de acordo com as diretivas de consentimento captadas pela execução mais recente de ApplyConsents e ApplyAdminConsents.

As seguintes regras aplicam-se quando faz um pedido com base no consentimento a uma FHIR store:

  • Forneça, pelo menos, um âmbito de consentimento actor relevante para as ações realizadas com consentimento.

  • Indique quaisquer âmbitos purpose e environment adicionais relevantes para as ações realizadas com consentimento.

  • Se o número de entradas do âmbito de consentimento exceder os limites suportados, é devolvido um erro.

  • Se chamar um método que aceda a vários recursos (por exemplo, o método fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle, ou fhir.search), a aplicação da imposição do consentimento aplica-se a cada recurso individual. No entanto, existe uma diferença subtil entre estes métodos de acesso a vários recursos:

    • fhir.executeBundle A leitura de vários recursos recebe "Acesso de consentimento negado ou o recurso acedido não existe" para recursos individuais sem autorizações de consentimento (consulte os exemplos em Obtenha recursos FHIR com âmbito de consentimento).

    • fhir.search ignora recursos sem autorizações de consentimento e não devolve um erro de acesso recusado por consentimento, mesmo para pesquisas por _id (veja exemplos na secção Pesquise recursos FHIR com âmbito de consentimento).

    • fhir.Patient-everything e fhir.Encounter-everything comportam-se de forma semelhante a fhir.search, exceto que devolvem "Acesso ao consentimento recusado ou o recurso acedido não existe" se o autor da chamada não tiver autorização de consentimento no recurso Patient ou Encounter pedido, respetivamente.

Uma diretiva de consentimento tem, no máximo, um actor, no máximo, um purpose e, no máximo, um environment, enquanto o âmbito do consentimento pode ter vários de cada. Algumas diretivas de consentimento não especificam todas as três propriedades do acessor. Nesse caso, qualquer valor da propriedade do âmbito de consentimento pode corresponder, consoante as regras de resolução de conflitos. Como resultado, um âmbito de consentimento pode corresponder a mais do que uma diretiva de consentimento.

Se o âmbito de consentimento de um pedido incluir duas ou mais entradas do mesmo tipo de âmbito de consentimento (actor, purpose ou environment), o âmbito de consentimento pode corresponder a várias diretivas de consentimento. Algumas diretivas de consentimento não especificam um purpose nem um environment. Por conseguinte, o âmbito do consentimento também tem de ser comparado com as diretivas de consentimento que não especificam estes tipos de âmbito.

Por exemplo, definir o âmbito do consentimento para actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc corresponde a qualquer uma das seguintes permit ou diretivas de consentimento: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

O que se segue?