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

Biztonság, adatvédelem és adattárolás helye

Hogyan védjük a páciens adatait: EU-s adattárolás, projekt izoláció, páros azonosítók, hitelesítő adatok, hozzájárulás, eredet, páciens által látható audit napló, és a privát béta korlátai.

Az orvosi adatok a legérzékenyebb adatok, amelyeket egy alkalmazás kezelhet. Ez az oldal felsorolja, hogyan védi az Anpheros Platform ma ezeket az adatokat – csak azt, ami már implementálva van –, valamint, hogy mi korlátozott még a privát béta során.

Adatmegőrzés

• Minden platformadat az Európai Unióban kerül tárolásra és feldolgozásra: a szolgáltatás és annak adatbázisai a Google Cloud europe-west4 (Hollandia) területén, a webhook kézbesítési sorban a europe-west3 (Frankfurt) területén, és a hozzáférési napló append-only exportja a BigQuery EU helyszínén található.
• USA adatrégió: kérésre elérhető a production ügyfelek számára HIPAA üzleti társulási megállapodás keretében (lásd alább); az USA betegadatok ekkor soha nem hagyják el az USA régiót.
• A dokumentumok egy EU tároló bucketben kerülnek tárolásra, amelyet ügyfél által felügyelt titkosítási kulcs (CMEK) titkosít. Az eredetik véglegesítés után módosíthatatlanok; SHA-256 ellenőrzőösszegük és méretük rögzítésre kerül.

Alkalmazások közötti elkülönítés

• Minden API kulcs egy projekthez tartozik. Egy projekt csak az általa létrehozott betegeket látja – a sandboxban, beleértve a saját szintetikus betegek másolatát is, amelyet egyetlen más projekt sem láthat.
• Párban azonosítók: minden projekt megkapja a saját azonosítóját ugyanazon személyhez; a belső azonosítók soha nem hagyják el a platformot, így az azonosítók nem korrelálhatók az alkalmazások között.
• Egy nem elérhető rekord 404-at válaszol, soha 403-et, így egy beteg létezése nem kérdezhető le.
• A sandbox és a production külön adatbázisok. Egy sandbox kulcs (sk_test_) fizikailag nem érheti el a valós betegeket.
• A beteg beleegyezésével egy szervezet elolvassa a teljes rekordot, beleértve azt is, amit más szervezetek írtak, de csak azt változtathatja meg vagy törölheti, amit maga írt.

Hitelesítő adatok

• Az API kulcsok csak egyszer jelennek meg, és csak SHA-256 hash-ként tárolódnak. A kulcsok read / write hatókörrel rendelkeznek, és soha nem lépik át a környezetüket.
• OAuth 2.1 kötelező PKCE-vel (S256); a redirect_uri-at pontosan regisztrálni kell. A hozzáférési tokenek 30 percig érvényesek, a frissítési tokenek 30 napig, és minden használatkor rotálódnak.
• Frissítési token újrafelhasználásának észlelése: egy már felhasznált frissítési token bemutatása megvonja a teljes tokenláncot.
• A token válaszok Cache-Control: no-store-et tartalmaznak. Az OpenID Connect id_token-ek RS256-tal vannak aláírva; a nyilvános kulcsok a /oauth/jwks címen érhetők el.

Hozzájárulás, eredet és auditálás

• A beteg egy hostolt hozzájárulási oldalon engedélyezi egy alkalmazásnak a hozzáférést, kiválasztva a rekordot és az időtartamot (30, 90, 180 vagy 365 nap). A hatókörök erőforrástípusonként és műveletenként értelmezendők, opcionálisan kategória szerint szűrve. Minden engedélyezés egy FHIR Consent erőforrásként kerül rögzítésre.
• A visszavonás a következő kérésre lép életbe; az alkalmazás nem tudja frissíteni a hozzáférést.
• Minden írási művelet létrehoz egy Provenance erőforrást: ki írta (beteg, gyakorló orvos, eszköz, import vagy AI), melyik szervezet számára, melyik forrásrendszerből.
• Minden olvasási művelet naplózva van és látható a beteg számára, beleértve a projekt saját API kulcsával végrehajtott olvasásokat, valamint az AI modellek számára felépített kontextust is.

Szállítás és webbiztonság

• Csak HTTPS, HTTP Strict Transport Security-vel. Az API válaszok korlátozó Content-Security-Policy-t, X-Content-Type-Options: nosniff, X-Frame-Options: DENY és szigorú referrer policy-t tartalmaznak.
• A webhook kézbesítések az időbélyegen és a törzsön keresztül HMAC-SHA256-tal vannak aláírva; a fogadóknak el kell utasítaniuk az 5 percnél régebbi aláírásokat. Az események azonosítókat és verziókat tartalmaznak, soha nem klinikai tartalmat.
• Sebességkorlátok: 600 kérés percenként hitelesítőnként és IP címenként; JSON törzsek legfeljebb 2 MiB; dokumentumok legfeljebb 25 MiB.

Keresőmotorok és AI-crawlerek

A nyilvános oldalak (anpheros.com, a platform bemutatója és ez a dokumentáció) nyitottak a keresőmotorok és az AI-crawlerek számára. Az API, az irányítópult, az OAuth és a hozzájárulási oldalak, valamint a páciensalkalmazás (app.anpheros.com) ki vannak zárva a noindex és robots.txt szabályokkal; egyik sem ad vissza páciensadatokat hitelesítés nélkül.

HIPAA (amerikai klinikák)

Egy Egyesült Államokbeli klinika számára az Anpheros Üzleti Partnernek minősül. Az alábbiakban a HIPAA Biztonsági Szabályzatnak megfelelően működik:

Üzleti Partner Megállapodás és amerikai adatrégió kérésre elérhető gyártási ügyfelek számára (írjon a [email protected] címre); az amerikai betegadatok gyártása a BAA aláírása után válik elérhetővé. A sandbox csak szintetikus betegeket tartalmaz, így az Egyesült Államokbeli fejlesztők ma BAA nélkül is tudnak fejleszteni. Az Anpheros nem rendelkezik SOC 2 vagy HITRUST tanúsítvánnyal; egy SOC 2 Type II audit akkor tervezett, ha egy kórházi ügyfél igényli azt.

Jelenlegi korlátok (privát béta)

• Egyzónás tárhely automatikus átkapcsolás nélkül; még nincs szerződéses SLA.
• A Production kulcsokat ellenőrzött szervezetek kapják meg, aláírt adatfeldolgozási megállapodással; a béta partnerek szintetikus adatokkal indulnak.
• A SMART EHR indítása és az OpenID nonce paraméter még nem támogatott.

Kapcsolódó

• GDPR és egészségügyi adatok fejlesztőknek
• Az orvosi adatok eredetének magyarázata: ki mit írt, és hogyan rögzítsük
• Hozzájárulási és hozzáférési modell
• Hitelesítés és OAuth
• Korlátok és sebességkorlátok
• Megbízhatóság, állapot és incidensek: monitorozás, biztonsági mentések, incidenskommunikáció
• Architektúra
• Az Európai Egészségügyi Adattér (EHDS) fejlesztőknek

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