Dane wrażliwe

Dane osobowe to szeroki temat, jakkolwiek szeroko lub wąsko rozumiany – dla wielu wrażliwych jest to temat bardzo drażliwy. Jednak niezależnie od tego jak bardzo dana osoba przejmuje się bezpieczeństwem czy poufnością danych powierzonych innym podmiotom (świadomie czy nie) to jednak ustawa na każdego administratora danych osobowych nakłada obowiązek takiego ich przetwarzania, przechowywania i transmitowania by ich spójność i bezpieczeństwo były gwarantowane (i zgodne z ustawą – bla, bla, bla).

Część danych pozwala na jednoznaczną identyfikację osoby (lub podmiotu), której dotyczą. Są to unikalne identyfikatory typu PESEl, NIP, czy REGON. Mniej oczywiste są identyfikatory typu nazwa / imię i nazwisko – które w skali globalnej wcale nie muszą być unikalne. Podobnie poszczególne fragmenty adresu zamieszkania / korespondencyjnego nie muszą precyzyjnie wskazywać konkretnej osoby lub grupy osób (pomijając nawet zmienność i rozbieżność takich danych w czasie – ludzie i firmy często zmieniają miejsce zamieszkania / prowadzenia działalności– także jeden adres może być współdzielony przez wiele podmiotów) ale już w połączeniu z imieniem i nazwiskiem lub datą urodzenia mogą zawęzić zbiór potencjalnych osób do jednego człowieka.

A nawet jeśli nie – to wskazanie konkretnej grupy osób (np. rodziny) może już być odebrane jako pogwałcenie prywatności. Należy bardzo uważać przy łączeniu danych – może się zdarzyć, że połączenie częściowo zamaskowanego adresu (np. do poziomu nazwy ulicy, ale już bez numerów mieszkań) z samym tylko faktem posiadania ubezpieczenia medycznego w konkretnej firmie może precyzyjnie identyfikować konkretną osobę! (A najprawdopodobniej nazwa firmy ubezpieczeniowej nie będzie podlegać anonimizacji, ze względu na wymagania biznesowe systemu testowego…)

Oczywiście, jeżeli wiemy, że dane w całej bazie zostały zanonimizowane wówczas wiemy, że wszelkie próby statystycznego zestawiania poszczególnych elementów nie mają wielkiego sensu. Pod warunkiem wszakże, że poziom anonimizacji jest wystarczający. Wydaje się, że można próbować wskazać właściwe poziomy minimalne dla poszczególnych danych. W wielu przypadkach okaże się, że można zwiększyć te poziomy, gdyż zbyt szeroki zakres realnych danych nie będzie potrzebny podczas korzystania z bazy de-identyfikowanej (np. adresy pozostaną prawdziwe do poziomu miast, związanego z testowanymi zapytaniami raportowymi). Losowa de-identyfikacja ma jedną zasadniczą wadę – może tworzyć osobowości, które fragmentarycznie odpowiadają prawdziwym podmiotom – imiona, nazwiska czy numery PESEL nie mają jakiejś gigantycznej zmienności. Jednym z wymogów może być, by wylosowane wartości anonimizacyjne były różne od oryginalnych. Ale już sprawienie by nie były identyczne z innymi w systemie – niekoniecznie. Pewnym problemem mogą okazać się indeksy unikalne (np. na PESEL, czy niepoprawny na kombinacji imienia i nazwiska), które uniemożliwią takie duplikaty – aplikacja powinna być przygotowana na taką ewentualność i albo sprawdzać to z góry (konfiguracja) albo przechwytywać stosowny wyjątek i losować nową wartość.

Wróćmy zatem do listy proponowanej przez HIPPA:

Czytaj dalej Dane wrażliwe

Anonimizacja vs de-identyfikacja

W pierwszej kolejności należałoby się zapoznać z różnicami między anonimizacją i de-identyfikacją.
Wg definicji (De-identification):

Anonymization
refers to irreversibly severing a data set from the identity of the data contributor in a study to prevent any future re-identification, even by the study organizers under any condition.
De-identification
is the process used to prevent a person’s identity from being connected with information. Common uses of de-identification include human subject research for the sake of privacy for research participants. Common strategies for de-identifying datasets are deleting or masking personal identifiers, such as name and social security number, and suppressing or generalizing quasi-identifiers, such as date of birth and zip code. The reverse process of defeating de-identification to identify individuals is known as re-identification.

Jak należy to rozumieć?

Anonimizacja
odnosi się do NIEODWRACALNEGO pozbawienia zbioru danych wszelkich wskazówek pozwalających na re-identyfikację osoby, której dotyczą.
De-identyfikacja

to usunięcie z danych wszelkich informacji OSOBISTYCH bezpośrednio lub pośrednio wskazujących na konkretną osobę, ale pozostawienie identyfikatora umożliwiającego ewentualne połączenie z oryginalnym zbiorem i osobą.

Generalnie, najlepiej by przedmiotowe dane pozbawić wszelkich możliwych powiązań z oryginalnymi danymi (pełna anonimizacja). Pytanie – czy jest to wykonalne?
Na pierwszy rzut oka – nie wydaje się to możliwe. Pracując na kopii danych, którą będziemy poddawali procesowi de-identyfikacji raczej pozostawimy w stanie niezmienionym wszelkie systemowe identyfikatory – klucze oraz klucze obce – odbudowanie wszelkich relacji o nie opartych wydaje się zadaniem zarówno skomplikowanym jak i wyjątkowo zasobożernym (bazy produkcyjne mają to do siebie, że zazwyczaj są duże). Może nie być to wskazane również ze względów operacyjnych – jeżeli anonimowa baza była używana do naprawy błędów – może zajść konieczność re-identyfikacji oryginalnych rekordów i ich naprawa.
Wniosek 1. W celu realizacji niektórych wymagań organizacji, aplikacja musi umożliwiać pozyskanie kopii danych poddanych jedynie procesowi de-identyfikacji. Musi być możliwość powiązania (przez osoby uprawnione, mające dostęp do oryginalnej bazy) wierszy oryginalnych i anonimowych.
Wniosek 2. Jednakże, na podstawie dowolnej analizy danych zawartych w przetworzonej kopii, bez posiadania dostępu do bazy oryginalnej, re-identyfikacja nie powinna być w żaden sposób możliwa.
Reasumując – jedynymi danymi umożliwiającymi re-identyfikację powinny zostać wewnętrzne identyfikatory z oryginalnego systemu, tj. identyfikatory nadane unikalnie przez ten system a nie pochodzące z innych systemów takie jak np. PESEL.

Czytaj dalej Anonimizacja vs de-identyfikacja