Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
API sanitaria con consenso del paziente
Come l'accesso a un fascicolo viene concesso dal paziente tramite ambiti (scopes) e durate OAuth 2.1, registrato e revocabile, cosa cambia nella progettazione di un'applicazione e come gli ID pairwise mantengono separate le applicazioni.
Un'API sanitaria con consenso del paziente è un'API in cui l'accesso a un record viene concesso dal paziente, per uno scopo, per un periodo di tempo, e può essere visualizzato e ritirato dal paziente, piuttosto che deciso una volta per tutte dall'organizzazione che detiene i dati. In Anpheros, il consenso non è un campo che si imposta; è il meccanismo attraverso il quale un'applicazione raggiunge un record. Questa guida spiega come funziona per uno sviluppatore e cosa cambia nella progettazione di un'applicazione.
Due modi per raggiungere un record
| Accesso organizzativo | Accesso concesso dal paziente | |
|---|---|---|
| Chi autorizza | la tua organizzazione, tramite una chiave API | il paziente, tramite una schermata di consenso OAuth 2.1 |
| Uso tipico | una clinica o un laboratorio che scrive risultati, la tua app che scrive per conto dei suoi utenti | un'app di terze parti, un assistente AI, uno strumento medico, un familiare |
| Ambito | i pazienti creati dalla tua organizzazione o che le sono stati condivisi | gli ambiti accettati dal paziente (patient/Observation.read, …) |
| Durata | finché la chiave è valida | la durata scelta dal paziente; rinnovabile, revocabile |
| Visibile al paziente | sì, nel log degli accessi | sì, con la possibilità di revoca |
Entrambi i percorsi passano attraverso la stessa API e lo stesso record FHIR. La differenza è chi detiene la chiave della porta.
Il flusso di consenso, passo dopo passo
- La tua applicazione invia il paziente all'endpoint di autorizzazione Anpheros con gli scope necessari e una motivazione in linguaggio chiaro.
- Il paziente visualizza la tua richiesta, sceglie una durata e accetta o rifiuta. La schermata è nella lingua del paziente.
- Ricevi un token di accesso limitato a quegli scope e a quel paziente. I token hanno una durata breve; i token di aggiornamento durano quanto il consenso.
- Ogni lettura e scrittura con quel token viene registrata con il nome della tua applicazione. Il paziente visualizza il log nella propria app.
- Se il paziente revoca il consenso, la richiesta successiva fallisce con un errore chiaro. Ricevi un webhook in modo da poter eseguire la pulizia.
Il flusso è standard OAuth 2.1 con PKCE e scope SMART on FHIR, quindi le librerie esistenti funzionano. La guida Authentication and OAuth contiene i parametri esatti e la guida Consent and access model le regole sottostanti.
Cosa cambia nella tua applicazione
- Chiedi di meno. Gli scope sono per tipo di risorsa e per direzione. Un'app che registra il peso chiede
Observation.read, non l'intero record. - Progetta per il ritiro. L'accesso può terminare in qualsiasi momento. Memorizza nella cache poco, rileggi quando necessario e gestisci l'errore di revoca come uno stato normale.
- Ottieni fiducia gratuitamente. I pazienti vedono il nome della tua applicazione, a cosa può accedere e quando ha letto qualcosa l'ultima volta. Le applicazioni che si comportano bene sono più facili da accettare.
- Scrivi con provenienza. Tutto ciò che scrivi porta la tua applicazione come autore e, quando pertinente, la persona per conto della quale è stata scritta. Il paziente e altre applicazioni possono distinguere i tuoi dati dai loro.
Identificatori che non espongono informazioni
Ogni applicazione vede un paziente sotto un identificatore pairwise: la stessa persona ha un ID diverso nella tua applicazione e in un'altra. Due applicazioni non possono unire i propri dati su una persona senza il consenso del paziente, anche se entrambe sono basate su Anpheros. Per il tuo codice questo è invisibile; per il paziente è la differenza tra consenso e formalità.
Famiglie e caregiver
Il consenso si estende alle persone che gestiscono record per conto di altri: un genitore per un figlio, un figlio adulto per un genitore anziano. Il record rimane associato all'account che lo ha creato; altri account ricevono l'accesso, che può essere revocato. La tua applicazione vede lo stesso meccanismo di consenso, con il caregiver come persona che accetta.
Correlati
- Modello di consenso e accesso
- Autenticazione e OAuth
- Backend SMART on FHIR
- API Sanitarie
- Sicurezza, privacy e residenza dei dati
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card