Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Consenso e modello di accesso

Chi vede cosa: isolamento progetti, ID pairwise, concessioni, proprietà di scrittura, provenienza e cosa vede il paziente di ogni applicazione con accesso.

Regola: con il consenso del paziente, un'organizzazione vede l'intero record — inclusi i dati scritti da altre cliniche — ma può modificare o eliminare solo ciò che ha scritto autonomamente. Ogni versione di ogni risorsa registra il progetto che l'ha scritta e l'organizzazione per conto della quale è stata scritta.

Chi vede cosa

• Un progetto (API key) vede i pazienti che ha creato. Sotto una grant (token OAuth) un'applicazione vede esattamente un paziente, attraverso tutti i writer, limitato agli scope concessi e ai filtri di categoria. Tutto il resto restituisce 404, mai 403, quindi gli ID non possono essere sondati.
• ID pairwise: ogni progetto riceve il proprio ID per la stessa persona; gli ID interni non lasciano mai la piattaforma. I riferimenti a pazienti al di fuori del tuo scope sono mascherati con un token opaco, per progetto.
• Directory (Organization, Practitioner, PractitionerRole): leggibile tramite ID attraverso il piano in modo che i riferimenti si risolvano; ricercabile solo all'interno del tuo progetto; utilizzabile come X-Anpheros-Acting-As / X-Anpheros-On-Behalf-Of solo quando è tuo.
• Sandbox e produzione sono database diversi. Una chiave sandbox fisicamente non può raggiungere pazienti reali.

Scritture e proprietà

• project_id su ogni versione della risorsa = lo scrittore. Aggiornamento/eliminazione da parte di un altro progetto → 403 con spiegazione; scrivi la tua risorsa invece.
• Provenance.agent.onBehalfOf = la clinica/organizzazione al momento della scrittura: X-Anpheros-On-Behalf-Of, altrimenti l'organizzazione del PractitionerRole in carica, altrimenti l'organizzazione del progetto.
• Ogni scrittura produce una risorsa Provenance e una riga di audit (chi, cosa, quando, sotto quale autorizzazione, quale applicazione, da quale impronta digitale sorgente).

Cosa vede il paziente

/me/patients/{id}/grants elenca ogni applicazione con accesso, i relativi scope e la scadenza; …/access-log elenca cosa è stato letto o scritto da ciascuna — sotto il consenso e con la chiave del progetto stesso. La revoca ha effetto alla richiesta successiva; l'applicazione non può più essere aggiornata. Con format=fhir il log di accesso viene restituito come un Bundle di risorse FHIR R4 AuditEvent, modellato secondo gli IHE Basic Audit Log Patterns (tipo rest, l'interazione come sottotipo, l'applicazione e la persona che agisce attraverso di essa come agenti, il paziente e la risorsa come entità, nessun dato clinico), in modo che un altro sistema possa unirlo alla visione della persona su chi ha avuto accesso al proprio record.

Cosa registra ogni risorsa Provenance e come impostarla: Spiegazione della provenienza dei dati medici.

SMART Health Links (condivisione tramite QR o link)

Una persona può condividere il proprio record senza un'applicazione intermedia: POST /me/patients/{id}/shl crea un SMART Health Link per il sottoinsieme di emergenza (allergie, farmaci, problemi, vaccinazioni — nessun risultato o cronologia) o l'International Patient Summary completo, con un passcode e una scadenza opzionali. La risposta trasporta l'URI shlink:/… (per un codice QR) e un indirizzo del visualizzatore su /shl/view, che lo apre in qualsiasi browser. Chiunque lo scansiona invia una richiesta all'URL del manifest e riceve il riepilogo come JWE (dir + A256GCM) crittografato con la chiave all'interno del link; qualsiasi lettore SMART Health Link funziona.

• Il contenuto viene generato ad ogni apertura (flag L, stato can-change), quindi una tessera conservata nel telefono rimane aggiornata.
• Un passcode (flag P) viene verificato sul server; dopo 10 tentativi errati il link smette di funzionare.
• GET /me/patients/{id}/shl elenca i link con la frequenza e il momento in cui ciascuno è stato aperto; …/shl/{link}/revoke disattiva uno alla volta. Ogni apertura è nel log di accesso.
• L'ID interno della persona non lascia mai la piattaforma: il documento li identifica tramite uno pseudonimo del link.

Gli agenti AI propongono, la persona decide

Sotto il consenso di una persona, una scrittura da parte di un agente AI (un'applicazione registrata come agente, ad esempio un assistente connesso tramite MCP) o qualsiasi scrittura con author_type ai non viene applicata immediatamente. La piattaforma la convalida e risponde 202 Accepted con l'ID della proposta (header Anpheros-Proposal); nulla cambia nel record. La persona la vede in GET /me/patients/{id}/proposals — cosa è, quale applicazione l'ha inviata — e la accetta o la rifiuta (…/proposals/{proposal}/accept o …/reject). Una proposta accettata viene scritta esattamente come inviata, contrassegnata come scritta dall'AI (HL7 AI Transparency). I progetti che possono vedere il record ricevono un webhook sottile proposal.created. Le scritture effettuate con la chiave del progetto stesso, su record creati dal progetto, non vengono trattenute.

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card