Vissza a BlograEgészségügy

HIPAA a felhőben: zero-knowledge PHI-védelemmel

Az üzleti társulási megállapodások nem akadályozzák meg a HIPAA-jogsértéseket, ha a felhő-MI-szállítód egyszerű szövegként dolgozza fel a PHI-t. Íme, mit jelent valójában a zero-knowledge architektúra az egészségügy számára.

March 10, 20269 perc olvasás
HIPAA compliancezero-knowledge architecturePHI anonymizationcloud securityBAA limitations

A megfelelési feltételezés, amelyet az egészségügyi szervezetek rosszul ítélnek meg

Minden felhő-MI-eszközt bevezető egészségügyi szervezet ugyanazt a tanácsot kapja a jogi csapattól: kössön Üzleti Társulási Megállapodást (BAA) a szállítóval, és HIPAA-megfelelő lesz.

A BAA-követelmény valódi. A HIPAA adatvédelmi szabálya megköveteli az érintett szervezetektől, hogy BAA-kat kössenek az üzleti társakkal — azokkal a szállítókkal, akik nevükben védett egészségügyi információt (PHI) hoznak létre, kapnak, tartanak fenn vagy továbbítanak. A klinikai feljegyzéseket feldolgozó MI-szállítónak BAA-ra van szüksége, mielőtt hozzányúl ezekhez az adatokhoz.

De a BAA-követelmény a szervezetek közötti szerződéses kapcsolattal foglalkozik. Nem foglalkozik azzal, hogy mi történik a PHI-val a szállító infrastruktúráján a szerződés aláírása után.

A kritikus kérdés nem az, hogy van-e BAA. Az, hogy a szállító hozzáférhet-e a PHI-hoz egyszerű szövegként — és mi történik ezekkel az adatokkal, ha incidenst szenvednek.

Mit fed valójában egy üzleti társulási megállapodás

Egy BAA meghatározza, hogy az üzleti társ:

  • Csak a megállapodásban meghatározott célokra használja a PHI-t
  • Megfelelő biztosítékokat vezet be a PHI védelme érdekében
  • Minden PHI-incidenst jelent az érintett szervezetnek
  • A megállapodás megszüntetésekor visszaadja vagy megsemmisíti a PHI-t

A BAA szerződéses kötelezettség. Az üzleti társ kötelezettséget vállal arra, hogy felelősségteljesen kezeli a PHI-t, megfelelő biztonságot vezet be, és értesíti az érintett szervezetet, ha valami rosszra fordul.

Ami a BAA nem tesz:

  • Nem akadályozza meg az üzleti társ rendszereinek feltörését
  • Nem szünteti meg az üzleti társ technikai hozzáférését a PHI-hoz visszafejtett formában
  • Nem védi az érintett szervezetet a HIPAA-felelősségtől, ha az üzleti társat feltörik

Amikor egy felhő-MI-szállítót feltörnek, és a szerver oldali tárolásuk visszafejthetetlen formában tartalmazza a betegeid PHI-ját, az incidens bejelentési kötelezettséget a BAA teljesíti — de a PHI-kitettség valóságos, a betegek kárt szenvednek, és az érintett szervezet HIPAA-érvényesítési vizsgálattal szembesül, függetlenül attól, hogy milyen szerződést írt alá.

A szerver oldali PHI-probléma

Az egészségügyi adatokat feldolgozó felhő-MI-eszközök alapvető architektúrán működnek: az adatok eljutnak a szállító szervereihez, ott az MI-modell feldolgozza, és az eredmények visszakerülnek a felhasználóhoz. Ahhoz, hogy ez működjön, a szállító infrastruktúrájának olyan formában kell hozzáférnie az adatokhoz, amelyet az MI-modell feldolgozhat.

Ez azt jelenti, hogy vagy az adatok titkosítatlanok a szállító szerverein, vagy a titkosítást a szállító kezeli a szállító által kontrolált kulcsokkal.

A szállító által kontrolált titkosítás nem végponttól végpontig titkosítás. Ha a szállító tartja a kulcsokat, a szállító visszafejtheti. Ha a szállító visszafejtheti, egy feltört szállítói szerver azonosítható formában teszi ki az adataidat.

Ez az architektúra az, amellyel a BAA-k nem foglalkoznak. A BAA megköveteli a szállítótól a „megfelelő biztosítékok” alkalmazását — de a szállító által kontrollált szerver oldali titkosítás szerződésesen teljesíti ezt a követelményt, még akkor is, ha semmilyen védelmet nem nyújt szállítói oldali incidensek ellen.

Az ilyen feltételekkel felhő-MI által feldolgozott egészségügyi adatok specifikus kockázati profilral rendelkeznek: a klinikai dokumentáció, számlázási kódok vagy kezelési tervek MI-segítségű előállításához felhasznált PHI olyan formában létezik a szállítói infrastruktúrán, amely olvasható, ha az infrastruktúrát feltörik.

A HIPAA-érvényesítés nem tesz különbséget „feltörtek minket, de volt BAA-nk” és „feltörtek minket” között. Az érintett szervezet betegeinek PHI-ja ki volt téve. Az érintett szervezetnek kötelessége volt megvédeni. A védelem technikai megvalósítása határozza meg, hogy a kötelezettséget teljesítették-e — nem a szerződés.

Mit változtat a zero-knowledge architektúra

A zero-knowledge architektúra az architektúra szintjén kezeli a szerver oldali hozzáférési problémát.

Mielőtt bármilyen fájl elhagyja a környezetét, a betegadatokat tokenekkel helyettesítik. Az MI-szállító anonimizált adatokat kap — strukturált tokenekkel helyettesített betegazonosítókat tartalmazó klinikai feljegyzéseket, neveket és számlaszámokat helyettesített számlázási rekordokat, demográfiai adatokat eltávolított kezelési terveket.

Az MI-modell az anonimizált tartalmat dolgozza fel és visszaküld eredményeket. Az érintett szervezet a tokenleképezés segítségével társítja vissza az eredményeket az eredeti betegrekordhoz, amelyet soha nem továbbítottak a szállítóhoz.

Ez mit változtat:

A szállító soha nem kap PHI-t. A zero-knowledge anonimizáláson átmenő klinikai feljegyzések nem tartalmaznak neveket, születési dátumokat, lakcímeket vagy egészségügyi nyilvántartási számokat. A szállító MI-modellje anonimizált adatokon dolgozik.

A szállítói incidens nem tesz ki PHI-t. Ha az MI-szállító infrastruktúráját feltörik, az ott tárolt adatok anonimizált tartalmat tartalmaznak beteg-azonosítható információ nélkül. Az incidens nem eredményezhet PHI-kitettséget, mert a PHI-t soha nem továbbították.

A BAA-követelmények magasabb szinten teljesíthetők. Az érintett szervezet technikai biztosítékokat valósított meg, amelyek meghaladják a szerződéses minimumot — nem azért, mert a BAA megköveteli, hanem mert az architektúra technikai lehetetlenné teszi a PHI-kitettséget ahelyett, hogy csupán szerződésesen tiltja.

A ténylegesen érvényes megfelelési szabvány

A HHS Polgári Jogok Irodájának HIPAA-érvényesítése arra összpontosít, hogy az érintett szervezetek megvalósítottak-e ésszerű és megfelelő biztosítékokat a PHI védelméhez. Az „ésszerű és megfelelő” értékelése a PHI kockázatára, a kompromittáció valószínűségére és az elérhető biztosítékok költségére irányul.

A BAA-k alapján PHI-t feldolgozó felhő-MI-szállítók tapasztaltak el incidenseket. A kockázat nem hipotetikus. Az érvényesítési vizsgálók által feltett kérdés az, hogy az érintett szervezet megvalósított-e olyan biztosítékokat, amelyek kezelik szállítói kapcsolataik ismert kockázati profilját.

Egy érintett szervezet, amely BAA-ra és szállítói kontrolált szerver oldali titkosításra támaszkodott, szerződéses megközelítést alkalmazott egy technikai problémához. Egy másik típus a betegek adatait anonimizálta, mielőtt bármit elküldött volna. Ez a forrásnál szüntette meg a kitettséget.

A második megközelítés kezeli az érvényesítési kérdést: a PHI soha nem volt a szállító birtokában használható formában. Nincs jelenteni való incidens, nincs értesítendő beteg, nincs reagálandó érvényesítési vizsgálat — mert az architektúra lehetetlenné tette a kudarc módját.

Azoknak az egészségügyi szervezeteknek, amelyek felhő-MI-bevezetést értékelnek, a megfelelési keretrendszer nem „szerezz BAA-t és haladj tovább”. Ez: „biztosítsd, hogy a PHI soha ne jusson el a szállítói környezetbe visszanyerhető formában”. A BAA teljesíti a szerződéses követelményt. A zero-knowledge architektúra teljesíti a technikait.

Források:

Készen áll az adatai védelmére?

Kezdje el a PII anonimizálását 273 entitástípuson 48 nyelven.