Esta página foi traduzida pela API Cloud Translation.

Modelo de dados de acesso e sistema de controle do FHIR

Nesta página, descrevemos como usar o sistema de controle de acesso FHIR da API Cloud Healthcare para gerenciar e proteger seus dados de saúde. É possível usar o controle de acesso do FHIR para definir políticas de consentimento, controlar o acesso a dados com base em papéis e contexto do usuário e aplicar essas políticas em um armazenamento do FHIR.

Visão geral do modelo de dados

O modelo de dados para controle de acesso é representado por recursos de consentimento. Elas definem as regras que se aplicam e a quais dados elas se referem.

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

As ações registradas em um consentimento FHIR podem ser amplas e lidar com mais do que apenas os dados do prontuário eletrônico (PEP) 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 se limita à leitura de dados FHIR de um armazenamento 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 os consentimentos que estão no estado ativo. Consentimentos em qualquer outro estado não têm efeito na aplicação. Se um consentimento for dado em nome de um paciente, ele será registrado como concedido por um profissional de saúde.

Tipo de política

A API Cloud Healthcare é compatível com os seguintes tipos de política de consentimento:

Consentimento do paciente: está associado a um paciente usando Consent.patient (STU3, R4) e vincula o máximo de dados possível, conforme definido 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 no armazenamento especificado 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 administrativa em cascata: um tipo de política administrativa que exige o URL da extensão https://g.co/fhir/medicalrecords/CascadingPolicy e o URL da extensão da política administrativa. É possível vincular esse tipo de política a um compartimento de recursos que correspondem aos critérios de recursos. Tem as seguintes limitações:
- Só é compatível com Patient (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. Entre em contato com o suporte do Cloud para usar esse recurso em um armazenamento FHIR sem integridade referencial.

É 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 faltando, 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 permitem ou negam o acesso a dados para uma entidade autorizada, como um beneficiário ou um acessante. 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 esta diretiva. Somente access é compatível para fornecer acesso somente leitura.
Critérios do acessador: 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 do acessor

A API Cloud Healthcare oferece suporte a três propriedades de um acessador para uso em uma diretiva de consentimento e para corresponder a um acessador que faz uma solicitação de acesso a dados. É necessário haver uma correspondência exata que diferencie maiúsculas de minúsculas para que uma diretiva seja aplicada no acessador como parte da determinação de acesso oferecida pelo servidor FHIR.

Essas propriedades são codificadas da seguinte forma:

Ator: representa um indivíduo, grupo ou função 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
Finalidade: ETREAT ou acesso para tratamento de emergência
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. Esse link não pode ser resolvido.

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

Critérios de recursos

A API Cloud Healthcare é compatível com os 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 está 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 recurso meta.tag (STU3, R4).
Rótulo de segurança: representa os rótulos de segurança que definem os recursos afetados, conforme identificado no campo meta.security (STU3, R4). Os seguintes sistemas de códigos são compatíveis:
- Confidencialidade: valores hierárquicos classificados de irrestrito 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: 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 habilitado para controle de acesso do FHIR. Um token externo com o escopo de consentimento (esquerda) é usado pelo aplicativo (#3) ao fazer uma solicitação para o armazenamento 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 do FHIR. Os valores dessas propriedades precisam corresponder exatamente (diferenciando maiúsculas de minúsculas) aos fornecidos em um consentimento para afetar 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 acesso relevantes precisam ser fornecidas como parte de uma solicitação HTTP FHIR para representar adequadamente esse acessador 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 um enfermeiro ou médico conhecido como profissional 444, membro do grupo 999, que representa profissionais de um departamento em um hospital específico. O profissional está lá para oferecer 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 de uma 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 finalidade de uso e as restrições ambientais atuais do acessor. Pode haver mais de uma dessas propriedades que representam o escopo de consentimento de um acessador a qualquer momento.

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

actor/{type}/{ID}: uma propriedade actor em que o recurso type é fornecido com o ID. 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 é um membro do conjunto de valores Finalidade de uso do FHIR (v3) ou da extensão dele. 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 solicitação HTTP do FHIR também podem receber escopos especiais, como btg e bypass, que são definidos da seguinte maneira:

btg: o recurso "Quebre o vidro" (BTG, na sigla em inglês) permite que você, como usuário humano, pule as verificações de consentimento em caso de emergência. Ele deve ser usado apenas em emergências e está sujeito a uma análise de 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 exige 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, aplicar o acesso e determinar as permissões pode ser uma tarefa difícil. Várias partes interessadas podem ter expectativas e requisitos diferentes em relação ao uso e à divulgação de informações do paciente. Para navegar por esse cenário complexo, é necessário entender claramente como o acesso é aplicado e a lógica subjacente que rege a determinação do acesso.

Política de consentimento agregado

Um consumidor de serviços de saúde, como um paciente ou 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 recursos de consentimento 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 para um determinado usuário e formam um conjunto de regras de consentimento agregadas.

Propriedades da diretiva de consentimento

A aplicação do 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 do controle de acesso conjunto do consentimento do paciente, da política de administrador e da política de administrador em cascata:

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 recursos e o proprietário do recurso são desconhecidos. A seguinte regra se aplica na ordem de listagem:
- Se o tipo de recurso pertencer ao compartimento do paciente ou ao compartimento do 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 do acessador, independente 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 recursos identificáveis (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 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 de pacientes (STU3, R4) ou de encontros (STU3, R4) precisam de pelo menos uma diretiva de consentimento de permissão por paciente ou política de administrador ou política de administrador em cascata e nenhuma diretiva de consentimento de negação do paciente e política de administrador e política de administrador em cascata. Essa condição é necessária para que o solicitante acesse todos os pacientes nomeados nos recursos.
- Alguns recursos podem oferecer suporte a vários participantes pacientes. Por exemplo, Appointment 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 transmissão em cascata de encontro, em que esse encontro faz referência a 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 nem transmitida para fins de verificação de acesso por 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 de saúde 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 ao realizar uma pesquisa de 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 wins over permit.

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

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:

A API Cloud Healthcare verifica as permissões na conta de serviço Google Cloud(ou principal) configurada no proxy. Se a conta de serviço tiver as permissões corretas do IAM para executar o método FHIR solicitado no armazenamento FHIR, a solicitação vai prosseguir.
Se a aplicação de consentimento estiver ativada na configuração do armazenamento FHIR e os cabeçalhos HTTP compatíveis com consentimento estiverem presentes, a API Cloud Healthcare vai aplicar as políticas de acesso por consentimento aos recursos do compartimento do paciente. 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.

Observação: se a configuração do armazenamento de FHIR definir o processamento do cabeçalho de consentimento como REQUIRED_ON_READ, o controle de acesso de consentimento será aplicado (e rejeitado) mesmo sem os cabeçalhos de consentimento.

As regras a seguir se aplicam ao fazer uma solicitação com reconhecimento de 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 aceitos, 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 ao ler vários recursos recebe "Acesso negado ao consentimento ou o recurso acessado não existe" para recursos individuais sem permissões de consentimento. Consulte exemplos em Receber recursos FHIR com escopo de consentimento.
- O fhir.search ignora recursos sem permissões de consentimento e não retorna o erro de acesso negado, mesmo ao pesquisar por _id. Consulte exemplos em Pesquisar recursos FHIR com escopo de consentimento.
- fhir.Patient-everything e fhir.Encounter-everything se comportam de maneira semelhante a fhir.search, exceto que retornam "Acesso negado ao consentimento ou o recurso acessado não existe" se o autor da chamada não tiver permissão de consentimento no recurso Patient ou Encounter solicitado, respectivamente.

Uma diretiva de consentimento tem no máximo um actor, um purpose e um environment, enquanto um escopo de consentimento pode ter vários de cada. Algumas diretivas de consentimento não especificam todas as três propriedades de acesso. Nesse caso, qualquer valor de propriedade de 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 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 ser comparado com diretivas 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 seguintes 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

Saiba como aplicar o acesso a um armazenamento FHIR.