# Biztonság, adatvédelem és adattartózkodási hely

> Hogyan védjük a páciens adatait: EU-s adattartózkodási hely, projekt elkülönítés, páronkénti azonosítók, hitelesítő adatok, hozzájárulás, eredet, a páciens számára látható auditnapló, valamint a privát béta korlátai.

Source: https://developers.anpheros.com/hu/guides/security

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 Partner**nek minősül. Az alábbiakban a HIPAA Biztonsági Szabályzatnak megfelelően működik:

| Biztonsági intézkedés | Hogyan teljesíti az Anpheros |
|---|---|
| Kijelölt felelősség, kockázatelemzés, írásbeli szabályzatok (§164.308) | Kinevezett Biztonsági Tisztviselő; éves kockázatelemzés; tíz írásbeli szabályzat (hozzáférés, titkosítás, naplózás, incidenskezelés, adatvédelmi incidens bejelentése, megőrzés és biztonsági mentés, képzés, eszközök, sürgősségi hozzáférés, beszállítók), hat évig megőrizve |
| Egyedi felhasználói azonosítás, hozzáférés-szabályozás (§164.312(a)) | Minden kulcs, token és személy saját azonosítóval rendelkezik; a projektek csak a saját betegeiket látják; a hozzájárulási hatókörök érvényesülnek minden olvasásnál; MFA vagy SSO szükséges a gyártási projekttel rendelkező szervezetek számára; automatikus kijelentkezés a műszerfalon |
| Auditálási ellenőrzések (§164.312(b)) | Minden olvasás és írás naplózva, hash-láncolva, csak hozzáadható módon exportálva; a beteg számára látható |
| Integritás (§164.312(c)) | Verziószámozott erőforrások, minden írásnál származási információ, megváltoztathatatlan dokumentumok SHA-256-tal |
| Átviteli biztonság (§164.312(e)) | TLS 1.2+, HSTS, aláírt webhookok, csak HTTPS alapú kézbesítések |
| Titkosítás tárolás közben | Az adatbázis és a biztonsági mentések titkosítva; a dokumentumok ügyfél által felügyelt kulcs alatt |
| Üzemzavar-elhárítási terv (§164.308(a)(7)) | Napi biztonsági mentések, időpont szerinti helyreállítás, 90 naponta helyreállítási gyakorlat rögzített időkkel |
| Adatvédelmi incidens bejelentése (§164.410) | A Fedett Entitást 5 munkanapon belül értesítjük a BAA-nk révén (törvény szerint 60 nap) |
| Üzleti partner lánc (§164.308(b)) | A Google Cloud a saját BAA-ja alatt; az alvállalkozók listája a BAA mellékletében található |

**Üzleti Partner Megállapodás** és **amerikai adatrégió** kérésre elérhető gyártási ügyfelek számára (írjon a platform@anpheros.com 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](https://developers.anpheros.com/hu/guides/gdpr-health-data-developers)
- [Az orvosi adatok eredetének magyarázata](https://developers.anpheros.com/hu/guides/medical-data-provenance): ki mit írt, és hogyan rögzítsük
- [Hozzájárulási és hozzáférési modell](https://developers.anpheros.com/hu/guides/consent)
- [Hitelesítés és OAuth](https://developers.anpheros.com/hu/guides/authentication)
- [Korlátok és sebességkorlátok](https://developers.anpheros.com/hu/guides/limits)
- [Megbízhatóság, állapot és incidensek](https://developers.anpheros.com/hu/guides/reliability): monitorozás, biztonsági mentések, incidenskommunikáció
- [Architektúra](https://developers.anpheros.com/hu/guides/architecture)
- [Az Európai Egészségügyi Adattér (EHDS) fejlesztőknek](https://developers.anpheros.com/hu/guides/ehds-for-developers)