# Pedidos de acesso a clínicas com aprovação do paciente (CIBA) > O fluxo OpenID CIBA por trás dos pedidos de acesso a clínicas: a receção insere o e-mail do paciente, o paciente aprova na aplicação ou por e-mail por 30, 90 ou 365 dias, e a aplicação da clínica recebe tokens. Source: https://developers.anpheros.com/pt/guides/clinic-access-request **Uma clínica acede ao registo de um paciente no Anpheros apenas quando o paciente o aprova.** A aplicação da clínica envia um pedido indicando o endereço de e-mail do paciente e o acesso de que necessita. O paciente recebe-o na aplicação Anpheros e por e-mail, vê quem está a pedir e para quê, escolhe por quanto tempo o permite e aprova ou recusa. Se aprovar, a aplicação da clínica recebe tokens e pode ler o registo até o acesso expirar ou o paciente o retirar. O fluxo é o fluxo padrão OpenID Connect Client-Initiated Backchannel Authentication (CIBA), em modo de poll. Existe para que um rececionista não precise de entregar um telefone ou um link ao paciente: o pedido vai para o paciente, não através do ecrã da clínica. ## Passo a passo 1. **A receção insere o e-mail do paciente.** A aplicação da clínica chama `POST /oauth/bc-authorize` com as suas credenciais de cliente, o e-mail do paciente como `login_hint`, o `scope` de que necessita e uma curta `binding_message` que o paciente verá. 2. **A plataforma responde da mesma forma para todos os endereços.** A resposta contém um `auth_req_id`, uma data de expiração e um intervalo de polling, independentemente de esse e-mail ter ou não uma conta Anpheros. Não revela quem tem um registo. Um pedido para uma pessoa sem conta simplesmente expira. 3. **O paciente decide.** Recebe uma notificação na aplicação Anpheros e um e-mail. O pedido mostra a organização, o âmbito e a mensagem. Escolhe um período de 30, 90 ou 365 dias e clica em permitir ou recusar. A ligação no e-mail não aprova nada quando é aberta, porque os scanners de e-mail abrem ligações; o paciente tem de clicar no botão. 4. **A clínica faz polling.** A aplicação chama `POST /oauth/token` com o tipo de concessão `urn:openid:params:grant-type:ciba` e o `auth_req_id`. Enquanto o paciente não decidiu, a resposta é `authorization_pending`. Após a aprovação, os tokens são devolvidos uma vez. Uma recusa devolve `access_denied` e um pedido não respondido devolve `expired_token`. 5. **A clínica lê e escreve dentro do âmbito concedido.** Cada leitura é registada e visível para o paciente. Uma clínica só pode alterar ou eliminar o que escreveu. ## O que protege o paciente - **Apenas email verificado.** Um pedido corresponde apenas a uma conta cujo email foi verificado, pelo que ninguém pode receber pedidos de outra pessoa ao criar uma conta com o seu endereço. - **Escopo e tempo limitado.** O acesso é por tipo de recurso e ação, por um período declarado. Um pedido ao qual ninguém responde expira por defeito no prazo de um dia e no máximo em sete dias. - **Revogável a qualquer momento.** A revogação entra em vigor no próximo pedido. A clínica não pode reativar o seu acesso. - **Visível.** O paciente vê todas as conexões e todos os acessos na aplicação. Ver [modelo de consentimento e acesso](https://developers.anpheros.com/pt/guides/consent). ## O que uma clínica precisa para construir - Um cliente OAuth confidencial registado na plataforma, com o seu segredo guardado no servidor. - Um ciclo de polling que respeite o intervalo e trate os quatro resultados. - Uma forma de mostrar a decisão do paciente à receção ("à espera do paciente", "aprovado até ...", "recusado"). - Gestão dos tokens devolvidos como credenciais de curta duração: os tokens de acesso duram 30 minutos e os tokens de atualização rodam a cada utilização. Ver [autenticação e OAuth](https://developers.anpheros.com/pt/guides/authentication). Para uma clínica que prefira abrir uma página de consentimento à frente do paciente, por exemplo na receção, o fluxo padrão de código de autorização com PKCE e lançamento autónomo SMART on FHIR também é suportado. ## Perguntas frequentes ### O paciente tem de estar na clínica? Não. Podem aprovar a partir do seu próprio telemóvel ou do link do e-mail, onde quer que estejam. Assim, um pedido pode ser enviado antes da consulta, e um paciente que esteja no estrangeiro ainda assim pode aprová-lo. ### E se o paciente não tiver conta Anpheros? O pedido é aceite e expira sem decisão, e a clínica não consegue saber se existe uma conta. O paciente pode criar uma conta e a clínica pode enviar um novo pedido. ### Quanto tempo dura o acesso? O paciente escolhe 30, 90 ou 365 dias quando aprova. Podem retirá-lo mais cedo. ### A clínica pode ver tudo no registo? Apenas o âmbito que o paciente aprovou. Os âmbitos são definidos por tipo de recurso e ação, e podem ser filtrados por categoria. ### O fluxo de pedidos é um padrão? Sim. É OpenID Connect CIBA, pelo que podem ser utilizadas bibliotecas OAuth existentes. Consulte o guia [API de saúde com consentimento do paciente](https://developers.anpheros.com/pt/guides/healthcare-api-patient-consent) para o modelo mais abrangente. ### Está em produção? Sim, na plataforma em beta privada. O acesso à produção necessita de uma organização verificada e de um acordo de processamento de dados assinado. ## Relacionado - [Uma plataforma de dados de pacientes para clínicas e hospitais](https://developers.anpheros.com/pt/guides/clinics-and-hospitals) - [Plataforma de consentimento do paciente para aplicações de saúde](https://developers.anpheros.com/pt/guides/patient-consent-platform) - [Como implementar o consentimento do paciente com SMART on FHIR](https://developers.anpheros.com/pt/guides/smart-on-fhir-backend) - [Segurança, privacidade e residência de dados](https://developers.anpheros.com/pt/guides/security)