# Richieste di accesso alla clinica con approvazione del paziente (CIBA) > Il flusso CIBA di OpenID dietro le richieste di accesso alla clinica: la reception inserisce l'email del paziente, il paziente approva nell'app o via email per 30, 90 o 365 giorni, e l'applicazione della clinica riceve i token. Source: https://developers.anpheros.com/it/guides/clinic-access-request **Una clinica accede al record di un paziente su Anpheros solo quando il paziente lo approva.** L'applicazione della clinica invia una richiesta nominando l'indirizzo email del paziente e l'accesso di cui necessita. Il paziente la riceve nell'app Anpheros e via email, vede chi sta chiedendo e per cosa, sceglie per quanto tempo consentirlo, e approva o rifiuta. Se approva, l'applicazione della clinica riceve i token e può leggere il record fino alla scadenza dell'accesso o al suo ritiro da parte del paziente. Il flusso è il flusso standard OpenID Connect Client-Initiated Backchannel Authentication (CIBA), in modalità poll. Esiste in modo che un receptionist non debba consegnare al paziente un telefono o un link: la richiesta va al paziente, non attraverso lo schermo della clinica. ## Passaggi 1. **La reception inserisce l'email del paziente.** L'applicazione della clinica chiama `POST /oauth/bc-authorize` con le sue credenziali client, l'email del paziente come `login_hint`, lo `scope` di cui ha bisogno e un breve `binding_message` che il paziente vedrà. 2. **La piattaforma risponde allo stesso modo per ogni indirizzo.** La risposta contiene un `auth_req_id`, una scadenza e un intervallo di polling, indipendentemente dal fatto che quell'email abbia o meno un account Anpheros. Non rivela chi ha un record. Una richiesta per una persona senza account semplicemente scade. 3. **Il paziente decide.** Riceve una notifica nell'app Anpheros e un'email. La richiesta mostra l'organizzazione, l'ambito e il messaggio. Sceglie un periodo di 30, 90 o 365 giorni e preme "consenti" o "rifiuta". Il link nell'email non approva nulla quando viene aperto, perché gli scanner di posta aprono i link; il paziente deve premere il pulsante. 4. **La clinica effettua il polling.** L'applicazione chiama `POST /oauth/token` con il grant type `urn:openid:params:grant-type:ciba` e il `auth_req_id`. Finché il paziente non ha deciso, la risposta è `authorization_pending`. Dopo l'approvazione, i token vengono restituiti una volta. Un rifiuto restituisce `access_denied` e una richiesta senza risposta restituisce `expired_token`. 5. **La clinica legge e scrive nell'ambito concesso.** Ogni lettura viene registrata e visibile al paziente. Una clinica può modificare o eliminare solo ciò che ha scritto autonomamente. ## Cosa protegge il paziente - **Solo email verificata.** Una richiesta corrisponde solo a un account la cui email è verificata, quindi nessuno può ricevere le richieste di un'altra persona creando un account con il proprio indirizzo. - **Con ambito e limitato nel tempo.** L'accesso è per tipo di risorsa e azione, per un periodo dichiarato. Una richiesta a cui nessuno risponde scade entro un giorno per impostazione predefinita e entro un massimo di sette giorni. - **Revocabile in qualsiasi momento.** La revoca ha effetto alla richiesta successiva. La clinica non può ripristinare il proprio accesso. - **Visibile.** Il paziente vede ogni connessione e ogni accesso nell'app. Vedere [modello di consenso e accesso](https://developers.anpheros.com/it/guides/consent). ## Cosa serve a una clinica per costruire - Un client OAuth confidenziale registrato sulla piattaforma, con il suo segreto conservato sul server. - Un ciclo di polling che rispetta l'intervallo e gestisce i quattro esiti. - Un modo per mostrare la decisione del paziente alla reception ("in attesa del paziente", "approvato fino al …", "rifiutato"). - Gestione dei token restituiti come credenziali di breve durata: i token di accesso durano 30 minuti e i token di aggiornamento ruotano ad ogni utilizzo. Vedere [autenticazione e OAuth](https://developers.anpheros.com/it/guides/authentication). Per una clinica che preferisce aprire una pagina di consenso di fronte al paziente, ad esempio alla scrivania, è supportato anche il flusso standard di codice di autorizzazione con PKCE e avvio standalone SMART on FHIR. ## Domande frequenti ### Il paziente deve essere in clinica? No. Possono approvare dal proprio telefono o dal link via email, ovunque si trovino. Pertanto, una richiesta può essere inviata prima dell'appuntamento e un paziente che si trova all'estero può comunque approvarla. ### Cosa succede se il paziente non ha un account Anpheros? La richiesta viene accettata e poi scade senza una decisione, e la clinica non può sapere se un account esiste. Il paziente può creare un account e la clinica può inviare una nuova richiesta. ### Quanto dura l'accesso? Il paziente sceglie 30, 90 o 365 giorni quando approva. Può ritirarlo prima. ### La clinica può vedere tutto nel record? Solo l'ambito che il paziente ha approvato. Gli ambiti sono impostati per tipo di risorsa e azione, e possono essere filtrati per categoria. ### Il flusso di richiesta è uno standard? Sì. È OpenID Connect CIBA, quindi è possibile utilizzare le librerie OAuth esistenti. Vedere la guida [healthcare API with patient consent](https://developers.anpheros.com/it/guides/healthcare-api-patient-consent) per il modello più ampio. ### È in produzione? Sì, sulla piattaforma in beta privata. L'accesso alla produzione richiede un'organizzazione verificata e un accordo di elaborazione dati firmato. ## Correlati - [Una piattaforma dati paziente per cliniche e ospedali](https://developers.anpheros.com/it/guides/clinics-and-hospitals) - [Piattaforma di consenso paziente per app sanitarie](https://developers.anpheros.com/it/guides/patient-consent-platform) - [Come implementare il consenso paziente con SMART on FHIR](https://developers.anpheros.com/it/guides/smart-on-fhir-backend) - [Sicurezza, privacy e residenza dei dati](https://developers.anpheros.com/it/guides/security)