Medicinos duomenys – tai turbūt jautriausia informacija, kokią apie save gali turėti žmogus. Jie atskleidžia ne tik ligas ar diagnozes, bet ir gyvenimo būdą, genetinę informaciją, psichinę sveikatą, priklausomybes, net seksualinę orientaciją per netiesioginius požymius. Kai tokia informacija patenka į skaitmeninę erdvę – o šiandien ji ten patenka beveik visada – privatumo klausimas nustoja būti teorinis. Tai tampa inžinerine, teisine ir organizacine problema, kurią sprendžia ne tik gydytojai, bet ir programuotojai, sistemų administratoriai bei duomenų apsaugos pareigūnai.
Kodėl medicinos duomenys yra kitokie
Palyginti su, tarkime, el. parduotuvės pirkimų istorija, sveikatos duomenys turi vieną esminį bruožą – jų negalima „atšaukti“. Jei nutekėjo kredito kortelės numeris, jį galima pakeisti per kelias minutes. Diagnozės, genetinio tyrimo rezultato ar psichiatro išvados pakeisti negalima niekada. Duomenys lieka aktualūs dešimtmečius, o kai kuriais atvejais – visą gyvenimą ir net po mirties (pavyzdžiui, genetinė informacija turi reikšmės giminaičiams).
Antra priežastis – šių duomenų vertė juodojoje rinkoje. Medicininiai įrašai su asmens kodais, adresais, draudimo informacija parduodami brangiau nei įprasti kredito kortelių duomenys, nes juos galima panaudoti sudėtingesniam sukčiavimui – nuo netikrų receptų iki tapatybės vagystės sveikatos draudimo sistemose. Būtent todėl ligoninių serveriai tapo mėgstamu ransomware atakų taikiniu – jei sustabdai IT sistemą operacinėje, personalas sutiks mokėti greičiau nei bet kuri kita organizacija.
Teisinis rėmas: BDAR ir kas už jo slypi
Europoje pagrindinis dokumentas – Bendrasis duomenų apsaugos reglamentas (BDAR arba GDPR). Sveikatos duomenys ten priskiriami „ypatingų kategorijų“ duomenims (9 straipsnis), kuriems taikoma griežtesnė apsauga nei, pavyzdžiui, vardui ar el. pašto adresui. Praktiškai tai reiškia, kad vien sutikimo dažnai neužtenka – turi būti teisinis pagrindas, aiškus tikslas, duomenų kiekio minimizavimas ir saugojimo terminų apibrėžimas.
Lietuvoje priežiūrą vykdo Valstybinė duomenų apsaugos inspekcija (VDAI), o sveikatos sistemoje papildomai galioja Sveikatos apsaugos ministerijos ir e-sveikatos sistemos reglamentai. Jei dirbi su e-sveikata.lt integracija, greitai pastebėsi, kad techninė specifikacija reikalauja ne tik autentifikacijos per elektroninius parašus ar SSO, bet ir griežto žurnalų (audit trail) tvarkymo – kiekvienas įrašo peržiūrėjimas turi būti fiksuojamas, nes vėliau gali kilti klausimas, kas ir kada matė paciento duomenis.
Svarbu suprasti ir pranešimo apie pažeidimą terminą – 72 valandos nuo sužinojimo apie incidentą iki pranešimo priežiūros institucijai. Sveikatos priežiūros įstaigose tai reiškia, kad IT komanda turi turėti paruoštą incidentų valdymo procesą dar prieš įvykstant pažeidimui, nes per tris paras neįmanoma sukurti procedūros nuo nulio.
Kur realiai slypi rizikos
Dažniausiai galvojama, kad didžiausia grėsmė – įsilaužėliai iš išorės. Realybėje statistika rodo kitką: didelė dalis incidentų kyla dėl vidinių veiksnių – neatsargaus darbuotojo, seno kompiuterio be atnaujinimų, USB laikmenos, kurioje eksportuoti pacientų sąrašai „darbui iš namų“. Kelios konkrečios problemos, su kuriomis susiduria sveikatos IT sistemos:
- Pasenusi programinė įranga. Daug ligoninių vis dar naudoja senas Windows versijas medicininei įrangai valdyti, nes gamintojas nebeteikia atnaujinimų naujesnėms sistemoms. Toks kompiuteris, prijungtas prie tinklo, yra atviras plyšys.
- Per plati prieiga. Kai visi darbuotojai turi tas pačias teises prie visos duomenų bazės, vietoj role-based access control (RBAC), bet koks nulaužtas paskyra tampa katastrofa.
- Trečiųjų šalių tiekėjai. Laboratorijos, vaizdo diagnostikos paslaugų teikėjai, debesijos infrastruktūra – kiekviena papildoma integracija yra papildomas duomenų perdavimo taškas, kurį reikia apsaugoti atskiru duomenų tvarkymo susitarimu (DPA).
- Nešifruoti backupai. Atsarginės kopijos dažnai lieka pamirštos saugumo audito metu – jos saugomos „kažkur“, bet retai kas patikrina, ar jos šifruotos taip pat griežtai kaip produkcinė duomenų bazė.
Šifravimas, anonimizavimas ir pseudonimizavimas – tai ne sinonimai
Šitas painiavos taškas kartojasi nuolat, todėl verta išsiaiškinti terminus atskirai.
Šifravimas (encryption) apsaugo duomenis techniškai – be rakto jų perskaityti neįmanoma. Sveikatos sistemose standartas yra AES-256 duomenims ramybėje (at rest) ir TLS 1.2/1.3 duomenims perdavimo metu (in transit). Tai apsaugo nuo pasyvaus perėmimo, bet jei asmuo turi teisėtą prieigą prie sistemos, šifravimas jo nesustabdys.
Pseudonimizacija – kai asmens duomenys pakeičiami pseudonimu (pvz., paciento ID vietoje vardo), bet susiejimo raktas išlieka atskirai. Tai naudinga moksliniams tyrimams ar analitikai, nes leidžia dirbti su duomenimis nematant tiesioginės tapatybės, tačiau teoriškai susiejimą galima atkurti – todėl BDAR požiūriu tai vis dar asmens duomenys.
Anonimizavimas – procesas, po kurio duomenų nebeįmanoma susieti su konkrečiu asmeniu jokiu pagrįstu būdu. Tikras anonimizavimas yra sunkiau pasiekiamas, nei atrodo – net pašalinus vardą ir asmens kodą, kombinacija amžiaus, pašto kodo ir retos diagnozės gali unikaliai identifikuoti asmenį mažoje bendruomenėje. Čia į pagalbą ateina metodai kaip k-anonimiškumas (užtikrinant, kad kiekvienas įrašas neatsiskiria nuo bent k-1 kitų įrašų) arba diferencinis privatumas (differential privacy), kai į duomenis įterpiamas kontroliuojamas triukšmas, neleidžiantis atkurti konkretaus asmens informacijos, bet išsaugantis statistinį naudingumą.
Debesija ir trečiųjų šalių tiekėjai
Vis daugiau sveikatos sistemų migruoja į debesiją – tai suprantama, nes skaičiavimo galia ir mastelio keitimas kainuoja mažiau nei savo serverinės palaikymas. Bet čia atsiranda papildomas klausimas – kur fiziškai saugomi duomenys ir kokia jurisdikcija galioja. BDAR nustato ribojimus duomenų perdavimui už ES/EEE ribų, todėl renkantis debesijos tiekėją (AWS, Azure, Google Cloud) svarbu patikrinti, ar egzistuoja ES regionas, kuriame galima izoliuoti duomenų saugojimą, ir ar tiekėjas pasirašo standartines sutartines sąlygas (SCC) arba turi BCR (Binding Corporate Rules).
Praktinis patarimas – reikalauti iš tiekėjo ISO 27001 sertifikato ir, jei įmanoma, HIPAA atitikties (nors tai JAV standartas, jis rodo, kad tiekėjas jau turi patirties su griežtais sveikatos duomenų reikalavimais). Taip pat verta reikalauti aiškaus duomenų tvarkymo susitarimo (Data Processing Agreement), kuriame apibrėžta, kas atsakingas incidento atveju ir kokia atsakomybė dalinama tarp duomenų valdytojo (ligoninės) ir duomenų tvarkytojo (debesijos tiekėjo).
Prieigos valdymas ir auditas kasdienėje praktikoje
Teorinės apsaugos priemonės neturi jokios vertės, jei jos neįdiegtos kasdieniame darbe. Keletas dalykų, kurie iš tiesų sumažina riziką:
- Multi-factor autentifikacija (MFA) visiems, kas prisijungia prie paciento duomenų sistemų, ne tik administratoriams.
- Principas „minimalios būtinos prieigos“ – slaugytoja mato tik savo skyriaus pacientus, laboratorijos darbuotojas mato tik tyrimų rezultatus, ne visą ligos istoriją.
- Automatinis atsijungimas po neaktyvumo laikotarpio – klasikinė situacija, kai kompiuteris registratūroje lieka atrakintas su atidarytu paciento profiliu, yra vienas dažniausių privatumo pažeidimo šaltinių.
- Reguliarus žurnalų peržiūrėjimas – ne tik jų kaupimas, bet ir automatizuota anomalijų detekcija (pvz., jei darbuotojas per naktį peržiūri 200 pacientų kortelių, tai turėtų sukelti įspėjimą).
Kai incidentas jau įvyko
Kad ir kaip gerai apsaugota sistema, verta turėti planą B. Sveikatos priežiūros įstaigos incidentų valdymo planas turėtų apimti keletą aiškių žingsnių: pirma, techninis izoliavimas (paveiktos sistemos atjungimas nuo tinklo, kad nutekėjimas nesiplėstų), antra, poveikio įvertinimas (kiek pacientų paveikta, kokio pobūdžio duomenys), trečia, pranešimas VDAI per 72 valandas, ir, jei rizika didelė, tiesioginis informavimas pacientams. Ketvirtas, dažnai pamirštamas žingsnis – po incidento analizė (post-mortem), kuri padeda išvengti to paties scenarijaus pasikartojimo.
Praktikoje daug organizacijų bijo pranešti apie incidentus dėl reputacijos rizikos, tačiau BDAR sistema numato, kad slėpimas baudžiamas griežčiau nei pats incidentas. Skaidrumas, nors ir nemalonus trumpuoju laikotarpiu, ilguoju yra pigesnis pasirinkimas.
Vietoj taško – ką verta įsidėti į kišenę
Jei reikėtų sutraukti visą šitą temą į keletą praktinių taisyklių, kurias galima taikyti tiek dirbant su medicinos IT sistema, tiek tiesiog rūpinantis savo, kaip paciento, duomenimis, jos atrodytų maždaug taip:
- Šifruok viską – ir duomenų bazę, ir backupus, ir komunikaciją tarp sistemų. Nėra „per daug šifravimo“, bet yra „per mažai“.
- Anonimizuok atsargiai – patikrink, ar tavo „anonimizuoti“ duomenys iš tiesų neatpažįstami, ypač jei imtis maža arba diagnozė reta.
- Riboki prieigą pagal principą „reikia žinoti“, o ne pagal patogumą IT komandai.
- Tikrink tiekėjus taip pat rimtai, kaip tikrini savo pačių sistemą – jų silpnybė tampa ir tavo silpnybe.
- Turėk paruoštą incidentų planą prieš jo prireikiant, ne po to.
- Kaip pacientas – domėkis, kur ir kam perduodami tavo duomenys, ir nebijok paklausti gydymo įstaigos, ar jos sistema atitinka BDAR reikalavimus.
Medicinos duomenų privatumas nėra vienkartinis projektas, kurį galima „užbaigti“ ir pamiršti. Tai nuolatinis procesas, kuriame technologija, teisė ir žmogiškas faktorius susipina kasdien. Kuo anksčiau organizacija priima šią mintį – ne kaip formalumą dėl BDAR audito, o kaip realią pareigą pacientui – tuo mažiau tikimybė, kad kada nors teks rašyti tą nemalonų pranešimą apie duomenų nutekėjimą.
