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.
Zero-knowledge megvalósítás esetén a PHI anonimizálva kerül, mielőtt elhagyja az érintett szervezet környezetét. 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, egészségügyi nyilvántartási számokat vagy más, HIPAA által meghatározott PHI-azonosítókat. 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 érintett szervezet, amely zero-knowledge anonimizálást alkalmazott, mielőtt PHI-t küldött volna MI-szállítókhoz, technikai megközelítést alkalmazott, amely megszüntette 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: