# Solicitări de acces la clinică cu aprobarea pacientului (CIBA) > Fluxul OpenID CIBA din spatele solicitărilor de acces la clinică: recepția introduce emailul pacientului, pacientul aprobă în aplicație sau prin email pentru 30, 90 sau 365 de zile, iar aplicația clinicii primește tokenuri. Source: https://developers.anpheros.com/ro/guides/clinic-access-request **O clinică ajunge la dosarul unui pacient pe Anpheros doar atunci când pacientul îl aprobă.** Aplicația clinicii trimite o solicitare numind adresa de email a pacientului și accesul de care are nevoie. Pacientul o primește în aplicația Anpheros și prin email, vede cine solicită și pentru ce, alege cât timp să permită accesul și aprobă sau refuză. Dacă aprobă, aplicația clinicii primește tokenuri și poate citi dosarul până când accesul expiră sau pacientul îl retrage. Fluxul este fluxul standard OpenID Connect Client-Initiated Backchannel Authentication (CIBA), în modul poll. Acesta există pentru ca un recepționer să nu fie nevoit să îi înmâneze pacientului un telefon sau un link: solicitarea ajunge la pacient, nu prin ecranul clinicii. ## Pas cu pas 1. **Recepția introduce emailul pacientului.** Aplicația clinicii apelează `POST /oauth/bc-authorize` cu credențialele sale de client, emailul pacientului ca `login_hint`, `scope` de care are nevoie și un scurt `binding_message` pe care pacientul îl va vedea. 2. **Platforma răspunde la fel pentru fiecare adresă.** Răspunsul conține un `auth_req_id`, o dată de expirare și un interval de polling, indiferent dacă acel email are sau nu un cont Anpheros. Nu dezvăluie cine are un cont. O cerere pentru o persoană fără cont pur și simplu expiră. 3. **Pacientul decide.** Primește o notificare în aplicația Anpheros și un email. Cererea afișează organizația, scopul și mesajul. Alege o perioadă de 30, 90 sau 365 de zile și apasă pe "permite" sau "refuză". Linkul din email nu aprobă nimic atunci când este deschis, deoarece scanerele de email deschid linkuri; pacientul trebuie să apese butonul. 4. **Clinica face polling.** Aplicația apelează `POST /oauth/token` cu tipul de grant `urn:openid:params:grant-type:ciba` și `auth_req_id`. Atâta timp cât pacientul nu a decis, răspunsul este `authorization_pending`. După aprobare, tokenurile sunt returnate o singură dată. Un refuz returnează `access_denied`, iar o cerere nesolicitată returnează `expired_token`. 5. **Clinica citește și scrie în cadrul scopului acordat.** Fiecare citire este înregistrată și vizibilă pentru pacient. O clinică poate modifica sau șterge doar ceea ce a scris ea însăși. ## Ce protejează pacientul - **Doar email verificat.** O cerere se potrivește doar cu un cont al cărui email este verificat, astfel încât nimeni nu poate primi cererile altei persoane prin crearea unui cont cu adresa sa. - **Cu scop și limitat în timp.** Accesul este per tip de resursă și acțiune, pentru o perioadă specificată. O cerere la care nimeni nu răspunde expiră implicit în decurs de o zi și cel mult șapte zile. - **Revocabil în orice moment.** Revocarea intră în vigoare la următoarea cerere. Clinica nu se poate reautentifica. - **Vizibil.** Pacientul vede fiecare conexiune și fiecare acces în aplicație. Vezi [modelul de consimțământ și acces](https://developers.anpheros.com/ro/guides/consent). ## Ce are nevoie o clinică pentru a construi - Un client OAuth confidențial înregistrat pe platformă, cu secretul său păstrat pe server. - O buclă de interogare (polling loop) care respectă intervalul și gestionează cele patru rezultate. - O modalitate de a afișa decizia pacientului la recepție ("așteptare pacient", "aprobat până la …", "refuzat"). - Gestionarea token-urilor returnate ca și credențiale cu durată scurtă de viață: token-urile de acces durează 30 de minute, iar token-urile de reîmprospătare (refresh tokens) se rotesc la fiecare utilizare. Vezi [autentificare și OAuth](https://developers.anpheros.com/ro/guides/authentication). Pentru o clinică ce preferă să deschidă o pagină de consimțământ în fața pacientului, de exemplu la ghișeu, este suportat și fluxul standard de cod de autorizare (authorization-code flow) cu PKCE și lansare independentă SMART on FHIR. ## Întrebări frecvente ### Pacientul trebuie să fie în clinică? Nu. Aceștia pot aproba de pe propriul telefon sau de pe linkul din e-mail, indiferent unde se află. Astfel, o cerere poate fi trimisă înainte de programare, iar un pacient care se află în străinătate o poate aproba în continuare. ### Ce se întâmplă dacă pacientul nu are un cont Anpheros? Cererea este acceptată și apoi expiră fără o decizie, iar clinica nu poate ști dacă există un cont. Pacientul poate crea un cont, iar clinica poate trimite o nouă cerere. ### Cât durează accesul? Pacientul alege 30, 90 sau 365 de zile atunci când aprobă. Aceștia îl pot retrage mai devreme. ### Clinica poate vedea totul în dosar? Doar scopul pe care pacientul l-a aprobat. Scopurile sunt setate pe tip de resursă și acțiune și pot fi filtrate după categorie. ### Fluxul de solicitare este un standard? Da. Este OpenID Connect CIBA, deci pot fi utilizate biblioteci OAuth existente. Consultați ghidul [API medical cu consimțământul pacientului](https://developers.anpheros.com/ro/guides/healthcare-api-patient-consent) pentru modelul mai larg. ### Este live? Da, pe platformă în beta privat. Accesul la producție necesită o organizație verificată și un acord de procesare a datelor semnat. ## Conexe - [O platformă de date pentru pacienți pentru clinici și spitale](https://developers.anpheros.com/ro/guides/clinics-and-hospitals) - [Platformă de consimțământ al pacientului pentru aplicații de sănătate](https://developers.anpheros.com/ro/guides/patient-consent-platform) - [Cum să implementați consimțământul pacientului cu SMART on FHIR](https://developers.anpheros.com/ro/guides/smart-on-fhir-backend) - [Securitate, confidențialitate și rezidența datelor](https://developers.anpheros.com/ro/guides/security)