Referencyjny projekt

Drugim czynnikiem uniemożliwiającym udostępnienie tej usługi jest sposób przechowywania i zapisu danych adresowych. Potwierdzenie danych adresowych polega na porównaniu wprowadzonego adresu z adresem zapisanym w bazie. W starej bazie PESEL adresy zapisywane są w sposób dowolny, tzn. ulica "A. Mickiewicza" może być zapisana również jako ulica "Adama Mickiewicza". W takim przypadku system nie potwierdzi poprawności adresu. Wskazany powyżej przykład jest tylko jednym z wielu. Można próbować automatycznie ujednolicić dane w tym zakresie, mimo to nadal pozostanie duża liczba przypadków wymagających ręcznej ingerencji, a i tak nie będzie pewności 100-proc. co do poprawności danych. PESEL 2 musi korzystać w tym zakresie z kodu TERYT, jednoznacznie definiującego ulice w danej miejscowości. Wiąże się to z modyfikacją aplikacji lokalnych w gminach.

Abstrahując od referencyjności danych i innych zagadnień technicznych, pozostaje jeszcze aspekt prawny. Do tej pory Główny Inspektor Danych Osobowych kilkakrotnie nie wyraził zgody na udostępnianie żadnej z wyżej wymienionych usług. Należy wyraźnie podkreślić, że bez odpowiednich regulacji prawnych systemu PESEL 2 nie będzie można uruchomić.

Integracja rejestrów na poziomie centralnym

System PESEL 2 to w głównej mierze referencyjna baza centralna, na podstawie której udostępniane będą dane przedsiębiorcom oraz procesy zachodzące wewnątrz administracji (np. proces zameldowania). W momencie, gdy rezygnuje się z jakichkolwiek działań na poziomie lokalnym, wszystkie żmudnie opracowywane procesy stają się bezużyteczne. Na czym będzie więc polegała integracja rejestrów na poziomie centralnym?

Na pewno dotyczyć będzie ewidencji ludności i dowodów osobistych. Są pomysły, żeby PESEL 2 i docelową wersję aplikacji OEWiUDO stworzyć siłami biura projektu, z pomocą konsultanta. Należy jednak wziąć pod uwagę, że biuro projektu nie jest firmą informatyczną o nieograniczonych zasobach i kompetencjach, dlatego też nie może podejmować się takich zadań. Natomiast, żeby zadanie to wykonała firma zewnętrzna, potrzeba czasu, którego nie ma na przeprowadzenie przetargów. Do tej pory nie jest opracowany choćby ogólny zarys wspomnianej integracji, nie mówiąc o szczegółowej specyfikacji przypadków użycia oraz zakresu danych wymienianych pomiędzy systemami. Spowodowane jest to zmianą założeń i koniecznością ponownego przygotowania projektu systemu. Co więcej, dane w ewidencji ludności w dużym stopniu różnią się od tych przechowywanych w systemie dowodowym. Problem budowy referencyjnej bazy centralnej nie leży więc w technice, tylko w jakości danych.

Referencyjna baza centralna a integracja lokalna

Podstawą świadczenia jakichkolwiek usług udostępniania danych przez system PESEL 2 jest referencyjna baza danych, za której rzetelność odpowiada państwo. Poza takim zapisem w ustawie muszą istnieć mechanizmy zapewniające odpowiednią jakość danych. Kluczowym czynnikiem mającym wpływ na referencyjność bazy centralnej jest sposób jej zasilania oraz opóźnienia w procesie aktualizacji. Aby osiągnąć referencyjność, niezbędne jest stworzenie niezawodnej łączności gmin z bazą centralną oraz lokalne ujednolicenie informacji o obywatelu.

Uzgodnienie danych pomiędzy systemami musi odbywać się lokalnie, ponieważ dane źródłowe dla bazy centralnej znajdują się właśnie w gminie. Obywatel kontaktując się z urzędnikiem, może osobiście wyjaśnić wszelkie zaistniałe nieścisłości. Rola MSWiA nie może ograniczyć się do zobowiązania gmin ustawą do przekazywania do centrum danych referencyjnych, ponieważ takie rozwiązanie nie przyniesie zamierzonych efektów. Co więcej, waga stworzenia referencyjnej bazy centralnej dla budowy nowoczesnej administracji publicznej jest nie do przecenienia. Z tego powodu odpowiedzialność za realizację ww. etapu musi spoczywać na Ministerstwie.

Największą zaletą rozpoczęcia budowy systemu od poziomu lokalnego jest fakt, że właścicielem praw autorskich do aplikacji lokalnych w gminach są firmy prywatne. Dlatego też, zgodnie z ustawą o zamówieniach publicznych, firmom tym można zlecić modyfikację ww. aplikacji bez długotrwałych procedur przetargowych. Modyfikacja ta miałaby na celu zastąpienie obecnie eksploatowanych aplikacji - do ewidencji ludności, dowodów osobistych i do prowadzenia akt stanu cywilnego - jedną uniwersalną aplikacją.

Obecnie w gminach urzędnicy na jednym stanowisku pracy mają po 3 komputery do różnych zastosowań. Nie dość, że urzędnik pracuje na 3 komputerach, to w dodatku musi ręcznie przepisywać dane pomiędzy nimi. Zdarza się również często, że dane jednego obywatela w tych trzech systemach się różnią. Uspójnienie tych danych to trudne i długotrwałe zadanie. Dlatego też Ministerstwo powinno zacząć właśnie od opracowania wytycznych, listy funkcji oraz stworzenia szczegółowej specyfikacji dla aplikacji lokalnych. Jest to konieczne, ponieważ w Polsce jest kilkanaście firm informatycznych rozwijających oprogramowanie gminne. Narzucenie standardów uporządkuje i ograniczy dowolność w tym zakresie. Ministerstwo powinno również dążyć, aby wszystkie możliwe pola były zesłownikowane, tzn. wybierane z listy. Takie rozwiązanie zapewnia jednoznaczność danego pola. Przykładowo, w Austrii wprowadzając adres zameldowania obywatela, z listy wybiera się miasto, następnie ulicę i nr domu. Zapobiega to wprowadzaniu błędnych danych.

Integracja systemów na poziomie lokalnym spełni również drugi postulat zapisany w Podstawowym Dokumencie Programu PESEL 2, mówiący o poprawie obsługi obywatela. Dla zobrazowania udogodnień związanych z wdrożeniem jednej uniwersalnej aplikacji posłużę się przykładem procesu wydawania dowodu osobistego. W przyszłości urzędnik będzie miał możliwość pobrania danych obywatela z ewidencji ludności, wydrukowania wniosku dowodowego, elektronicznego potwierdzenia stanu cywilnego. Gdy dowód zostanie już wyprodukowany i przekazany obywatelowi, informacja o tym zdarzeniu automatycznie trafi do ewidencji ludności.

Dla referencyjności danych w bazie centralnej niezbędna jest szybka i sprawna komunikacja szczebla lokalnego z centralnym. W tym celu można skorzystać z już istniejących rozwiązań, np. łączności bezprzewodowej GPRS używanej w systemie wydawania dowodów osobistych. Takie rozwiązanie nie jest jednak rozwiązaniem docelowym. Należy się zastanowić nad równoległym tworzeniem infrastruktury sieciowej połączenia zapasowego (opartego na GPRS) i docelowego (wykorzystującego Internet i VPN). W ten sposób system cechowałby się większą niezawodnością działania, przy relatywnie niewielkim, dodatkowym nakładzie finansowym.