Hogyan tegye egészségügyi alkalmazását HIPAA-konformmá

A HIPAA többek között a betegek egészségügyi adatait védi.

A legnagyobb amerikai biztosítótársaság, az Anthem a saját bőrén tanulta meg ezt.

Az, ami egy egyszerű adathalász e-maillel kezdődött, a történelem legnagyobb egészségügyi adatvédelmi incidenséhez vezetett. A hackerek 79 millió beteg adatait lopták el. Az információk között szerepelt nevük, társadalombiztosítási számuk és orvosi azonosítójuk.

A feldühödött betegek beperelték az Anthemet, és 115 millió dolláros kártérítést nyertek. Bár a vállalat elkerülte a szabályozó hatóság bírságát, akár 260 millió dollárt is költenie kell a biztonságának javítására.

A HHS Polgári Jogi Hivatala (OCR) felügyeli a HIPAA betartását. Csak 2017-ben közel 20 millió dollárra bírságolta az amerikai egészségügyi szolgáltatókat.

Még ha kis szervezetről van szó, a HIPAA-követelmények elhanyagolása komoly problémákhoz vezethet.

A Fresenius Medical Care North America 2013-ban öt adatszegést követett el. Ezek együttesen mindössze 525 beteg adatait tárták fel. A vállalatnak mégis monstre 3,5 millió dolláros bírságot kellett fizetnie, mert nem elemezte megfelelően a biztonsági kockázatokat.

A gondatlanság mértéke szerint a HIPAA-bírságoknak négy foka létezik:

HIPAA glosszárium

Ezt a három kulcsfontosságú fogalmat kell megértenie, mielőtt a HIPAA-követelményekkel foglalkozik.

• Védett egészségügyi információ (PHI) – minden olyan adat, amely a beteg azonosítására használható.

A PHI két részből áll: egészségügyi információkból és személyes azonosítókból. Az utóbbiak közé tartoznak a betegek nevei, címei, születési dátumai, társadalombiztosítási számai, orvosi feljegyzések, fényképek stb. Az a tény, hogy egy személy orvosi ellátásban részesült, önmagában PHI-nek minősül.

Mit tekintünk PHI-nek? A teljes lista.

• Érintett szervezetek – az egészségügyi szolgáltatásokat/műveleteket nyújtó vagy azokért fizetést elfogadó szervezetek és személyek.

Ezek közé tartozik minden egészségügyi szolgáltató (pl. kórházak, orvosok, fogorvosok, pszichológusok), egészségügyi terv (pl. biztosítók, HMO-k, állami programok, mint a Medicare és a Medicaid) és elszámolóházak (az egészségügyi szolgáltatók és a biztosítók között közvetítőként működő szervezetek).

• Üzlettársak – a PHI-t az érintett szervezetek nevében kezelő harmadik felek.

Ez a kategória magában foglalja az egészségügyi alkalmazások fejlesztőit, a tárhely/adattároló szolgáltatókat, az e-mail szolgáltatásokat stb.

A HIPAA szerint minden olyan féllel, aki hozzáfér a PHI-hez, üzleti társulási megállapodást (BAA) kell kötnie. Ha úgy dönt, hogy nem ír alá BAA-t, az nem mentesíti Önt a HIPAA követelményei alól.

Az érzékeny adatok számos nem szándékos módon kerülhetnek az Ön rendszerébe.

Vegyünk például egy olyan szolgáltatást, amely lehetővé teszi az orvosok számára, hogy anonim fényképek alapján diagnosztizálják a bőrbetegségeket. Az alkalmazás nem kezeli a PHI-t, mivel nem tudja azonosítani a felhasználóit. De amint a fotókhoz hozzáadja a személy nevét vagy címét, azok PHI-vé válnak.

Ha az alkalmazása PHI-t gyűjt, tárol vagy továbbít az érintett szervezetek felé, meg kell felelnie a HIPAA-nak.

Hogyan válhat HIPAA-konformá?

A HIPAA-nak való megfeleléshez rendszeresen technikai és nem technikai értékeléseket kell végeznie az egészségügyi információk védelmére tett erőfeszítéseiről, és ezeket alaposan dokumentálnia kell. A szabályozó hatóság közzétett egy minta auditálási protokollt, amely segíthet Önnek a HIPAA-megfelelőség értékelésében.

Független auditorral is elvégeztetheti az értékelést. Számos olyan szervezet létezik, mint például a HITRUST, amelyek az ilyesmire szakosodtak. Csak ne feledje, hogy az OCR nem ismeri el a harmadik féltől származó tanúsítványokat.

Technikai biztosítékok. Biztonsági intézkedések, például bejelentkezés, titkosítás, vészhelyzeti hozzáférés, tevékenységi naplók stb. A törvény nem határozza meg, hogy milyen technológiákat kell használnia a PHI védelmére.

A fizikai biztosítékok célja a PHI-t tároló létesítmények és eszközök (szerverek, adatközpontok, PC-k, laptopok stb.) biztosítása.

A modern felhőalapú megoldásoknál ez a szabály leginkább a HIPAA-konform tárhelyre vonatkozik.

A törvény az orvosi szoftverek széles körére vonatkozik. Egy kórházi irányítási rendszer (HMS) gyökeresen különbözik a távdiagnosztikai alkalmazásoktól. Van azonban néhány olyan funkció, amely minden HIPAA-kompatibilis alkalmazás esetében elengedhetetlen.

Íme tehát a HIPAA-kompatibilis szoftverek szükséges funkcióinak minimális listája:

1. Hozzáférés-szabályozás

Minden olyan rendszernek, amely PHI-t tárol, korlátoznia kell, hogy ki tekintheti meg vagy módosíthatja az érzékeny adatokat. A HIPAA adatvédelmi szabály szerint senki sem láthat több betegadatot, mint amennyi a munkája elvégzéséhez szükséges. A szabály meghatározza továbbá az azonosítástól való megfosztást, a betegek jogait a saját adataik megtekintésére, valamint azt a képességüket, hogy hozzáférést adjanak vagy korlátozzák a PHI-jükhöz.

Ez megvalósításának egyik módja, hogy minden felhasználóhoz egyedi azonosítót rendelnek. Ez lehetővé tenné a rendszerhez hozzáférő személyek tevékenységének azonosítását és nyomon követését.

A következő lépésben minden felhasználónak meg kell adnia a jogosultságok listáját, amelyek lehetővé teszik számukra bizonyos információk megtekintését vagy módosítását. Szabályozhatja az egyes adatbázis-egységekhez és URL-ekhez való hozzáférést.

A felhasználó alapú hozzáférés-szabályozás legegyszerűbb formájában két adatbázis-táblából áll. Az egyik tábla az összes jogosultság és azonosítójuk listáját tartalmazza. A második táblázat ezeket a jogosultságokat az egyes felhasználókhoz rendeli.

Ebben a példában az orvos (felhasználói azonosító 1) létrehozhatja, megtekintheti és módosíthatja a kórlapokat, míg a radiológus (felhasználói azonosító 2) csak frissítheti azokat.
A szerepkör-alapú hozzáférés-szabályozás egy másik módja ennek a követelménynek a megvalósítására. Ezzel a felhasználók különböző csoportjaihoz rendelhet jogosultságokat a beosztásuktól függően (pl. orvosok, laboránsok, adminisztrátorok).

2. Személy vagy szervezet hitelesítése

A jogosultságok kiosztása után a rendszernek képesnek kell lennie annak ellenőrzésére, hogy a PHI-hez hozzáférni próbáló személy az-e, akinek vallja magát. A törvény több általános módot kínál arra, hogy ezt a biztosítékot megvalósítsa:

A jelszó az egyik legegyszerűbb hitelesítési módszer. Sajnos egyben az egyik legkönnyebben feltörhető is. A Verizon szerint az adatbetörések 63%-a gyenge vagy ellopott jelszavak miatt történik. Egy másik jelentés szerint a vállalati felhasználók egyötöde rendelkezik könnyen kompromittálható jelszóval.

Az igazán biztonságos jelszó viszont:

• Legalább 8-12 karakterből áll, amelyek nagybetűket, számokat és speciális karaktereket tartalmaznak;
• Kizárja a gyakran használt kombinációkat (pl. “jelszó”, “123456”, “qwerty” és valamilyen megmagyarázhatatlan okból “monkey”) és a szókapcsolatokat;
• Kizárja a felhasználónév bármilyen variációját;
• megakadályozza a jelszó újrafelhasználását.

Változatlanul lehet egy véletlenszerű szavakból álló, beton jégkrémként összetört sorozat is.

Az alkalmazás ellenőrizheti ezeket a követelményeket a bejelentkezési képernyőn, és megtagadhatja a hozzáférést a gyenge jelszóval rendelkező felhasználóktól.

Túl sok biztonság nem létezik. Forrás: mailbox.org

Egyes szervezetek arra kényszerítik alkalmazottaikat, hogy körülbelül 90 naponként változtassák meg a jelszavakat. Ha ezt túl gyakran teszi, az valójában árthat a biztonsági erőfeszítéseknek. Amikor a jelszavak megváltoztatására kényszerítik az embereket, gyakran találnak ki nem eredeti kombinációkat (pl. jelszó ⇒ pa$$word).

Márpedig a hackerek másodpercek alatt feltörhetnek egy rossz jelszót, és azonnal felhasználhatják.

Ezért érdemes megfontolni a kétfaktoros hitelesítés használatát. Az ilyen rendszerek a biztonságos jelszót egy második ellenőrzési módszerrel kombinálják. Ez lehet bármi, a biometrikus leolvasótól kezdve az SMS-ben kapott egyszer használatos biztonsági kódig.

A gondolat egyszerű: még ha a hackerek valahogyan meg is szereznék a jelszavát, a PHI-hoz való hozzáféréshez el kellene lopniuk az eszközét vagy az ujjlenyomatát.

A biztonságos hitelesítés azonban nem elég. Egyes támadók bejuthatnak a felhasználó eszköze és az Ön szerverei közé. Így a hackerek a fiók veszélyeztetése nélkül hozzáférhetnének a PHI-hoz. Ezt nevezik munkamenet eltérítésnek, egyfajta man-in-the-middle támadásnak.

A munkamenet eltérítésének egyik lehetséges módja. Forrás: Forrás: Heimdal Security

A digitális aláírás az ilyen támadások elleni védekezés egyik módja. A jelszó ismételt megadása egy dokumentum aláírásakor bizonyítaná a felhasználó személyazonosságát.

Amint a rendszerben a szerepek egyre összetettebbé válnak, a HIPAA-engedélyezés a betegek segítésének útjába állhat. Érdemes bevezetni a vészhelyzeti hozzáférést. Az ilyen eljárások lehetővé teszik a felhatalmazott felhasználók számára, hogy bármely szükséges adatot megtekinthessenek, ha a helyzet úgy kívánja.

Egy orvos például vészhelyzetben bármely beteg PHI-jéhez hozzáférhet. A rendszer ugyanakkor automatikusan értesítene több más személyt, és elindítana egy felülvizsgálati eljárást.

3. Az adatátvitel biztonsága

A hálózaton keresztül és a rendszer különböző szintjei között küldött PHI-t meg kell védenie.

Ezért minden kommunikációhoz (vagy legalábbis a regisztrációs képernyőkhöz, a PHI-t és az engedélyezési sütiket tartalmazó összes oldalhoz) HTTPS-t kell erőltetnie. Ez a biztonságos kommunikációs protokoll SSL/TLS segítségével titkosítja az adatokat. Egy speciális algoritmus segítségével a PHI-t olyan karaktersorozattá alakítja, amely a dekódoló kulcsok nélkül értelmezhetetlen.

Az SSL-tanúsítványnak nevezett fájl a kulcsot az Ön digitális személyazonosságához köti.

Az alkalmazással való HTTP-kapcsolat létrehozásakor a böngésző lekéri a tanúsítványt. Az ügyfél ezután ellenőrzi annak hitelességét, és kezdeményezi az úgynevezett SSL kézfogást. Az eredmény egy titkosított kommunikációs csatorna a felhasználó és az Ön alkalmazása között.

Hogy engedélyezze a HTTPS-t az alkalmazása számára, szerezzen be egy SSL-tanúsítványt az egyik megbízható szolgáltatótól, és telepítse azt megfelelően.

Egyébként ügyeljen arra, hogy a PHI-t tartalmazó fájlok elküldéséhez a hagyományos FTP helyett biztonságos SSH vagy FTPS protokollt használjon.

SSL kézfogás; forrás: az SSL áruház

Az e-mail nem biztonságos módja a PHI elküldésének.

A népszerű szolgáltatások, például a Gmail, nem nyújtanak megfelelő védelmet. Ha PHI-t tartalmazó e-maileket küld a tűzfalas szerveren kívülre, akkor azokat titkosítania kell. Számos olyan szolgáltatás és böngészőbővítmény létezik, amely ezt elvégezheti Ön helyett. Alternatív megoldásként használhat egy HIPAA-konform e-mail szolgáltatást, például a Pauboxot.

Egy olyan szabályzatot is be kell vezetnie, amely korlátozza az e-maileken keresztül megosztható információkat.

4. Titkosítás/dekódolás

A titkosítás a legjobb módja a PHI sértetlenségének biztosításának. Még ha a hackereknek sikerülne is ellopniuk az adatokat, azok a dekódoló kulcsok nélkül halandzsának tűnnének.

A titkosítatlan laptopok és más hordozható eszközök a HIPAA megsértésének gyakori forrásai. A biztonság kedvéért titkosítja minden olyan eszköz merevlemezét, amely PHI-t tartalmaz. Ezt olyan ingyenes titkosítási eszközökkel teheti meg, mint a BitLocker Windowshoz vagy a FileVault Mac OS-hez.

5. A PHI megsemmisítése

A PHI-t véglegesen meg kell semmisítenie, ha már nincs rá szükség. Amíg annak másolata az Ön valamelyik biztonsági másolatában marad, az adat nem minősül “megsemmisítettnek”.

2010-ben az Affinity Health Plan visszaadta fénymásolóit a lízingcégnek. Nem törölte azonban a merevlemezeiket. Az ebből eredő biztonsági rés több mint 344 000 beteg személyes adatait hozta nyilvánosságra.

Az Affinitynek 1,2 millió dollárt kellett fizetnie az eset miatt.

APHI sok váratlan helyen rejtőzhet: fénymásolók, szkennerek, biomedicinális berendezések (pl. MRI- vagy ultrahangkészülékek), hordozható eszközök (e.pl. laptopok), régi floppylemezek, USB flash meghajtók, DVD-k/CD-k, memóriakártyák, alaplapok és hálózati kártyák flashmemóriája, ROM/RAM memória stb.

Az adatok törlésén túlmenően a PHI-t tartalmazó adathordozókat is megfelelően meg kell semmisíteni, mielőtt kidobja vagy elajándékozza őket. A helyzettől függően törölheti őket mágnesesen (pl. degausserrel), felülírhatja az adatokat olyan szoftverrel, mint a DBAN, vagy fizikailag megsemmisítheti a meghajtót (pl. kalapáccsal összetörheti).

A flash-alapú memóriameghajtókon (pl. USB-stickek) az adatok a kopás megelőzése érdekében az egész adathordozón eloszlanak. Emiatt az érzékeny információkat nehéz teljesen törölni a szokásos adatmegsemmisítő szoftverekkel. A flash meghajtók megsemmisítéséhez azonban használhatja a gyártó segédprogramjait, például a Samsung Magician Software-t (vagy egyszerűen csak használjon kalapácsot).

6. Adatmentés és tárolás

A biztonsági mentések elengedhetetlenek az adatok sértetlenségéhez. Egy adatbázis sérülése vagy egy szerver összeomlása könnyen kárt okozhat a PHI adataiban. Akárcsak egy tűz az adatközpontban vagy egy földrengés.

Ezért fontos, hogy PHI-jének több példányát több különböző helyen tárolja.

A PHI biztonsági mentési tervének meg kell határoznia az adatok veszélyeztetésének valószínűségét. Minden magas és közepes kockázatú információról naponta biztonsági másolatot kell készíteni, és azt biztonságos helyen kell tárolni. BAA-t is alá kell írnia a biztonsági mentés szolgáltatóival.

A biztonsági mentés haszontalan, ha nem tudja visszaállítani.

2016 augusztusában a Martin Medical Practice Concepts zsarolóprogram-támadás áldozatává vált. A vállalat fizetett a hackereknek, hogy visszafejtsék a PHI-t. A biztonsági mentés meghibásodása miatt azonban a helyi kórházak 5000 beteg adatait veszítették el.

A helyreállítási hibák megelőzése érdekében rendszeresen tesztelje rendszerét. Naplóznia kell a rendszer leállási idejét és a PHI biztonsági mentésének esetleges hibáit is.

És ne feledje, hogy maguknak a biztonsági mentéseknek is meg kell felelniük a HIPAA biztonsági szabványoknak.

7. Ellenőrzési ellenőrzések

Az ellenőrzési ellenőrzések hiánya magasabb bírságokhoz vezethet.

Követnie kell, hogy mit tesznek a rendszerében tárolt PHI-vel. Jegyezze fel minden egyes alkalommal, amikor egy felhasználó be- és kijelentkezik a rendszeréből. Tudnia kell, hogy ki, mikor és hol férhetett hozzá az érzékeny adatokhoz, frissíthette, módosíthatta vagy törölhette azokat.

A felügyelet történhet szoftveres, hardveres vagy eljárási eszközökkel. Egy egyszerű megoldás az lenne, ha egy adatbázisban vagy naplófájlban egy táblázat segítségével rögzítenénk a betegadatokkal való összes interakciót.

Egy ilyen táblázatnak öt oszlopból kell állnia:

• user_id. A PHI-vel interakcióba lépett felhasználó egyedi azonosítója;
• entity_name. Az entitás, amellyel a felhasználó interakcióba lépett (Az entitás valamilyen valós fogalom reprezentációja az adatbázisban, pl. egy egészségügyi rekord);
• record_id. Az entitás azonosítója;
• action_type. Az interakció jellege (létrehozás, olvasás, frissítés vagy törlés);
• action_time. Az interakció pontos időpontja.

A példában egy orvos (user_id 1) létrehozta egy beteg rekordját, egy radiológus megtekintette azt, majd később ugyanez az orvos módosította a rekordot.

A tevékenységi naplókat rendszeresen ellenőrizni kell, hogy felfedezze, ha egyes felhasználók visszaélnek a jogosultságaikkal a PHI-hez való hozzáféréssel.

8. Automatikus kijelentkezés

A PHI-t tartalmazó rendszernek automatikusan meg kell szüntetnie minden munkamenetet egy meghatározott inaktivitási időszak után. A folytatáshoz a felhasználónak újra meg kellene adnia a jelszavát, vagy más módon engedélyeznie kellene magát.

Ez megvédi a PHI-t, ha valaki elveszíti az eszközét, miközben bejelentkezett az alkalmazásba.

A kijelentkezést kiváltó inaktivitás pontos időtartamának a rendszer sajátosságaitól kell függenie.

Egy biztonságos, fokozottan védett környezetben lévő munkaállomás esetében az időzítőt 10-15 percre állíthatja be. Webalapú megoldások esetén ez az időtartam nem haladhatja meg a 10 percet. Mobilalkalmazás esetén pedig 2-3 percre állíthatja be az időkorlátot.

A különböző programozási nyelvek különböző módon valósítják meg az automatikus kijelentkezést.

Forrás: MailChimp

9. Mobilalkalmazások extra-biztonsága

A mobileszközök számos további kockázatot jelentenek. Egy okostelefont könnyen ellophatnak vagy elveszíthetnek egy nagy forgalmú területen, veszélyeztetve az érzékeny adatokat.

Ezek megelőzésére használhat:

• Képernyőzárat (Android/iOS);
• Teljes készüléktitkosítás (Android/iOS);
• Távoli adattörlés (Android/iOs).

Ezeket a funkciókat nem kényszerítheti a felhasználókra, de ösztönözheti az embereket a használatukra. Beillesztheti az utasításokat a bevezetésbe, vagy küldhet e-maileket, amelyekben leírja, hogyan lehet ezeket engedélyezni.

Tipp: A PHI-t a személyes adatoktól elkülönítve, biztonságos tárolóban is tárolhatja. Így távolról törölheti az egészségügyi adatokat anélkül, hogy bármi mást érintene.

Sok orvos használ személyes okostelefonokat egészségügyi információk küldésére. Ezt a fenyegetést biztonságos üzenetküldő platformokkal semlegesítheti.

Az ilyen alkalmazások biztonságos adatbázisban tárolják az érzékeny adatokat. A PHI eléréséhez a felhasználóknak le kell tölteniük az üzenetküldőt, és be kell jelentkezniük a fiókjukba.

Egy másik megoldás a titkosított, jelszóval védett egészségügyi portálok, ahol a betegek elolvashatják az orvosok üzeneteit. Az ilyen portálok olyan értesítéseket küldenek, amelyekben nincs PHI (pl. “Kedves felhasználó, új üzenetet kapott “).

Ne feledjük, hogy a push-értesítések alapértelmezés szerint nem biztonságosak. Akkor is megjelenhetnek a képernyőn, ha az le van zárva. Ezért győződjön meg róla, hogy nem küld semmilyen PHI-t push-értesítéseken keresztül. Ugyanez vonatkozik az SMS-ekre és az automatikus üzenetekre is.

Forrás:

Egy másik dolog, amit figyelembe kell venni, hogy az FDA egyes mHealth-alkalmazásokat orvosi eszközöknek (az egészségügyi szakemberek döntéshozatali folyamatát befolyásoló szoftvereknek) minősíthet.

Azért ne felejtse el ellenőrizni, hogy az alkalmazásnak meg kell-e felelnie más egészségügyi előírásoknak, mielőtt elkezdi a fejlesztést. A gyors válaszhoz megnézheti ezt a Federal Trade Commission által készített tesztet.

Befoglalva

Most már megvan a HIPAA-kompatibilis szoftverek jellemzőinek minimális listája.

Ezek önmagukban nem garantálják a biztonságát. Nem védik meg az adathalászattól vagy a social engineeringtől.

De ezeknek a funkcióknak a megléte meggyőzheti az auditorokat arról, hogy eleget tettek az ügyfelek adatainak védelme érdekében.

Az auditok megkönnyítése érdekében dokumentálja az összes HIPAA-megfelelőségi erőfeszítéseit. Az alkalmazás minden egyes kiadásához adja meg az írásos specifikációkat, a biztonság tesztelésére vonatkozó terveket és azok eredményeit. És ne felejtse el ellenőrizni, hogy a fejlesztés megkezdése előtt meg kell-e felelnie más előírásoknak is.