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

Consimțământ și model de acces

Cine vede ce: izolare proiect, ID-uri pereche, granturi, proprietate asupra scrierii, proveniență și ce vede pacientul despre fiecare aplicație cu acces.

Regulă: cu consimțământul pacientului, o organizație vede întregul dosar — inclusiv ce au scris alte clinici — dar poate modifica sau șterge doar ceea ce a scris ea însăși. Fiecare versiune a fiecărui resursă înregistrează proiectul care a scris-o și organizația în numele căreia a fost scrisă.

Cine vede ce

• Un proiect (cheie API) vede pacienții pe care i-a creat. Sub o acordare (token OAuth), o aplicație vede exact un pacient, de la toți autorii, limitat la domeniile acordate și filtrele de categorie. Tot restul returnează 404, niciodată 403, astfel încât ID-urile nu pot fi interogate.
• ID-uri pereche: fiecare proiect primește propriul ID pentru aceeași persoană; ID-urile interne nu părăsesc niciodată platforma. Referințele la pacienți din afara domeniului dvs. sunt mascate cu un token opac, per proiect.
• Director (Organizație, Practician, RolPractician): citibil prin ID pe întreg planul, astfel încât referințele să se rezolve; căutabil doar în cadrul proiectului dvs.; utilizabil ca X-Anpheros-Acting-As / X-Anpheros-On-Behalf-Of doar când este al dvs.
• Sandbox și producție sunt baze de date diferite. O cheie de sandbox fizic nu poate accesa pacienți reali.

Scrieri și proprietate

• project_id la fiecare versiune a resursei = scriitorul. Actualizare/ștergere de către alt proiect → 403 cu o explicație; scrieți propria resursă în schimb.
• Provenance.agent.onBehalfOf = clinica/organizația la momentul scrierii: X-Anpheros-On-Behalf-Of, altfel organizația rolului Practicianului care acționează, altfel organizația proiectului.
• Fiecare scriere produce o resursă Provenance și o înregistrare de audit (cine, ce, când, sub ce grant, ce aplicație, de la ce amprentă sursă).

Ce vede pacientul

/me/patients/{id}/grants listează fiecare aplicație cu acces, scopurile acesteia și data expirării; …/access-log listează ce a citit sau scris fiecare — sub consimțământ și cu cheia proprie a proiectului. Revocarea intră în vigoare la următoarea cerere; aplicația nu se mai poate reînnoi. Cu format=fhir, jurnalul de acces revine ca un Bundle de resurse FHIR R4 AuditEvent, modelat după IHE Basic Audit Log Patterns (tipul rest, interacțiunea ca subtip, aplicația și persoana care acționează prin ea ca agenți, pacientul și resursa ca entități, fără date clinice), astfel încât un alt sistem îl poate integra în vizualizarea persoanei despre cine a accesat înregistrarea sa.

Ce înregistrează fiecare resursă Provenance și cum să o setați: Medical data provenance explained.

SMART Health Links (partajare prin QR sau link)

O persoană își poate partaja dosarul fără o aplicație intermediară: POST /me/patients/{id}/shl creează un SMART Health Link pentru subsetul de urgență (alergii, medicamente, probleme, imunizări — fără rezultate sau istoric) sau complet International Patient Summary, cu un parolă opțională și dată de expirare. Răspunsul transportă URI-ul shlink:/… (pentru un cod QR) și o adresă de vizualizare pe /shl/view, care îl deschide în orice browser. Oricine îl scanează postează la URL-ul manifestului și primește rezumatul ca JWE (dir + A256GCM) criptat cu cheia din interiorul link-ului; orice cititor SMART Health Link funcționează.

• Conținutul este generat la fiecare deschidere (flag L, status can-change), astfel încât un card păstrat în telefon rămâne actualizat.
• O parolă (flag P) este verificată pe server; după 10 încercări greșite, link-ul încetează să funcționeze.
• GET /me/patients/{id}/shl listează link-urile cu frecvența și momentul în care a fost deschis fiecare; …/shl/{link}/revoke dezactivează unul dintr-o dată. Fiecare deschidere este în log-ul de acces.
• ID-ul intern al persoanei nu părăsește niciodată platforma: documentul îi numește printr-un pseudonim al link-ului.

Agenții AI propun, persoana decide

Sub consimțământul unei persoane, o scriere efectuată de un agent AI (o aplicație înregistrată ca agent, de exemplu, un asistent conectat prin MCP) sau orice scriere cu author_type ai nu este aplicată imediat. Platforma o validează și răspunde cu 202 Accepted cu ID-ul propunerii (header Anpheros-Proposal); nimic nu se schimbă în înregistrare. Persoana o vede în GET /me/patients/{id}/proposals — ce este, ce aplicație a trimis-o — și o acceptă sau o respinge (…/proposals/{proposal}/accept sau …/reject). O propunere acceptată este scrisă exact așa cum a fost trimisă, marcată ca fiind scrisă de AI (HL7 AI Transparency). Proiectele care pot vedea înregistrarea primesc un webhook subțire proposal.created. Scrierile efectuate cu cheia proprie a unui proiect, pe înregistrări create de proiect, nu sunt reținute.

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