Privaatsus arhitektuuris terviserakendustes. Miks ainult kohapealne salvestus loeb vähihaige kaaslasrakenduses.

Terviserakenduse esimene kujundusotsus pole see, milliseid ekraane joonistada. See on otsus, kus andmed elavad. See üks valik kandub edasi õiguslikku arhitektuuri, regulatiivsesse rada, kasutajate usaldussuhtesse ja lõpuks toote pikaajalisse ellujäämisvõimesse. Vähipatsiente raviteel toetava rakenduse puhul ei ole sellele valikule valesti vastamine joonealune märkus. See on kogu lugu.

See essee pakub praktiseeriva üksikarendaja vaatest argumenti, et ainult kohapealne salvestus on kõige paremini kaitstav lähtepunkt tundlikele terviserakendustele. Mitte sellepärast, et see on moes, ja mitte sellepärast, et see on mugav. Kumbki ei vasta tõele. Aga sellepärast, et alternatiiv nõuab palju raskemat vastavus- ja töökoormust, kui väike meeskond suudab kanda ja samal ajal head toodet teha.

Kategooria, kuhu andmed kuuluvad

Euroopa isikuandmete kaitse üldmääruse järgi ei ole terviseandmed tavalised isikuandmed. Need kuuluvad artikli 9 alla andmete eriliigina, biomeetriliste andmete, geneetiliste andmete ja seksuaalse sättumuse kõrval. Nende töötlemiseks on vaja selget nõusolekut või ühte väikesest hulgast õiguslikest alustest. Ka siis ootab määrus, et vastutavad töötlejad rakendavad tundlikkusega proportsionaalseid kaitsemeetmeid.

Rinnavähi kaaslasrakenduse puhul kuuluvad asjasse puutuvad andmed selgelt sellesse kategooriasse. Diagnoosi kuupäevad, raviskeemid, kõrvalmõjud, ravimite ajakavad, vaimse seisundi näitajad. Kõik. Hetkel, mil selline rakendus hakkab seda serverisse salvestama, saab arendajast eriliigi andmete vastutav töötleja koos kõige sellega kaasnevaga: mõjuhinnang, tehnilised ja korralduslikud meetmed, rikkumisteate kohustused ja suhe järelevalveasutustega, mida ei eksisteeri, kui andmed seadmest kunagi välja ei lähe.

Arhitektuurne valik

Ainult kohapealne salvestus tähendab praktikas seda, et rakendus loeb ja kirjutab patsiendi andmeid ainult seadme kaitstud salvestusalasse. Pilvekontosse sünki pole. Serveripoolset varukoopiat pole. Andmeid ei edastata kolmandatele osapooltele: ei analüütika, ei krahhi raportite, ei TI-töötluse jaoks.

Sellel lähenemisel on selged kulud. Seadme kaotanud kasutajad kaotavad oma andmed. Mitme seadmega kasutajad ei näe sama kirjet üle nende. Taastamise võimalused piirduvad sellega, mida operatsioonisüsteem ise pakub (näiteks iCloud Backup, mis on krüpteeritud, kuid toimub rakenduse kontrolli alt välja jääval kihil). Need on päris kompromissid ja kasutajale tuleb need selgelt öelda.

Mis võidetakse, on struktuurne. Rakendus pole enam eriliigi andmete vastutav töötleja selles tähenduses, mis käivitaks GDPR raskemad kohustused. Pole murekohaks serveririkkumist, sest serverit pole. Pole küsimust, millises jurisdiktsioonis andmeid töödeldakse, sest neid töödeldakse ainult ühes kohas: kasutaja enda telefonis. Kasutaja on oma kirje sõnasõnalise füüsilise valduse omanik.

Regulatiivne kasu

GDPR kõrval tasub sama arhitektuurne valik end ära ka meditsiiniseadmete regulatsiooni rajal. ELi meditsiiniseadmete määruse järgi sõltub rakenduse klassifikatsioon ja sellega seotud vastavushindamise koormus osaliselt riskidest, mida tarkvara sisse toob. Rakendus, mis kunagi midagi ei edasta, ei agregeeri ega tee mingit töötlust peale kohapealse logimise ja visualiseerimise, on olemuselt madalama riskiga kui rakendus, mis seda teeb.

See ei tähenda, et selline rakendus saab automaatselt I klassi. Klassifikatsioon sõltub kavandatud otstarbest. Aga see tähendab küll, et tehniline dokumentatsioon, riskianalüüs ISO 14971 järgi ja kliiniline hindamine MDR alusel on kõik lihtsamad ja ausamad, kui kaitsta on vähem. Regulatiivse poole kohta üksikasjalikumalt vaata MDR-rada üksikarendajatele.

Kõige paremini kaitstav terviserakendus on see, mis teeb andmetega kõige vähem. Ja on selles aus.

Usalduskasu

On olemas ka vaiksem kasu, raskemini mõõdetav, kuid kergesti tuntav: usaldus. Aktiivses ravis olevad patsiendid on kurnatud, hirmunud ja skeptilised järjekordse ettevõtte suhtes, kes nende andmeid küsib. Selge avaldus, et andmed elavad ainult nende telefonis ja kuskil mujal koopiat ei ole, mõjub väga teistmoodi kui lõik sellest, kuidas andmed on edastuses ja salvestuses krüpteeritud tööstuse standardkaitsetega.

Esimest laadi avaldust saab kasutaja telefoni välja lülitades ise kontrollida. Teist tuleb tal usule võtta. Tõsise haiguse ajal kasutatava rakenduse puhul on see vahe oluline.

Mida see praktikas tähendab

Väikese stuudio jaoks, kes sellist rakendust ehitab, kujundab ainult kohapealne salvestus kogu tehnilise virnaga. iOSi puhul tähendab see platvormi turvalise salvestuse hoolikat kasutamist, tähelepanu sellele, millised varukoopia mehhanismid andmeid hõlmavad, ja kasutaja selget valikut, kas osaleda ükskõik millises lisaeksporti võimaluses. See tähendab, et kolmandate osapoolte analüütika SDKsid ei kasutata. Et krahhi raportite teenust, mis kasutaja andmeid sisse võtab, ei kasutata. Et rakendus kirjutatakse nii, nagu arendaja andmeid mitte kunagi ei näeks. Sest ei nähagi.

See on piiratum viis tarkvara ehitada. See välistab paljud mugavused, millele väikesed meeskonnad tavaliselt toote analüütika, funktsioonide lipuga testimise ja kaughäälestuse jaoks toetuvad. Vahetus tasub end ära ühe rakenduste klassi puhul: sellise, kus andmed on nii tundlikud, et nende kõige turvalisem koht on kasutaja enda taskus.

Lühike märkus selle kohta, mis see ei ole

Ainult kohapealne salvestus ei ole iseenesest privaatsusgarantii. Rakendus võib endiselt saata telemeetriat, küsida tarbetuid lubasid või lekkida andmeid halvasti kujundatud jagamisfunktsioonide kaudu. Arhitektuur on vundament, mitte viimistlus. Aga see on vundament, mis muudab kõik, mis selle peale ehitatakse, kergemini kaitstavaks, kergemini kontrollitavaks ja kasutajale kergemini usaldatavaks.

Vähihaige kaaslasrakenduse puhul on see vundament lähtepunkt, mitte optimeerimine.

Sagedased küsimused

Mida tähendab „privaatsus arhitektuuris” terviserakenduse puhul praktikas?

See tähendab, et andmekaitse on ankurdatud arhitektuuri, mitte hiljem lisatud vastutuse välistustesse. Terviserakenduse puhul tähendab see, et patsiendi andmed on salvestatud ainult kasutaja seadmesse, mitte kunagi serverisse. Sünki, pilvevarukoopiat ega edastust kolmandatele osapooltele analüütika, krahhi raportite ega TI-töötluse jaoks ei toimu.

Millised GDPR sätted on terviserakenduste puhul kõige olulisemad?

Terviseandmed kuuluvad GDPR artikli 9 alla isikuandmete eriliigina. Nende töötlemiseks on vaja selget nõusolekut või ühte väikesest hulgast õiguslikest alustest. Vastutavad töötlejad peavad rakendama tundlikkusega proportsionaalseid kaitsemeetmeid, viima läbi mõjuhinnangu artikli 35 järgi ja täitma rikkumisteate kohustusi artikli 33 järgi.

Millised on ainult kohapealse salvestuse tagasilöögid terviserakendustes?

Kolm peamist kulu: seadme kaotanud kasutajad kaotavad oma andmed, mitme seadme kasutus on piiratud, ja taastamine sõltub sellest, mida operatsioonisüsteem pakub (iOSi puhul iCloud Backup). Võit on struktuurne: vabanemine serveririkkumise riskist, jurisdiktsiooniküsimustest ja paljudest GDPR vastutava töötleja kõige raskematest kohustustest.

Kuidas mõjutab ainult kohapealne salvestus ELi MDR-rada?

Rakendus, mis ei edasta kunagi midagi, ei agregeeri ega tee mingit töötlust peale kohapealse logimise, on olemuselt madalama riskiga. See parandab riskianalüüsi ISO 14971 järgi ja kliinilist hindamist, kuid ei aseta seadet automaatselt I klassi. Lõplik klassifikatsioon sõltub kavandatud otstarbest.