Protokół z Prezentacji projektu „Helios – Integracja rejestrów

Protokół z Prezentacji projektu „Helios – Integracja rejestrów publicznych w
wykorzystaniem Krajowej Szyny Usług”
Dyrektor Christow wprowadzając przedstawił, że jest to rozwiązanie problemu zaprojektowane, tak
aby systemy publiczne się widziały i mogły komunikować. Dla jednych systemów jest potrzeba zgoda,
dla innych potrzebny wniosek dostępu do danych. Chcemy pokazać, że są rozwiązania techniczne,
które pozwalają wyzbyć się pewnych zaszłości. Jest to związane z tym, że musimy dostosować się do
Ustawy o informatyzacji, z której wynikają zadania do realizacji. Mówimy tu o integracji, ale bardziej
o integracji semantycznej, nie planujemy natomiast budować jednej słusznej bazy danych. Podział
resortowy zostaje, natomiast dążymy do tego, aby był wspólny punkt dostępu do informacji. Na celu
mamy wypracowanie i ugruntowanie wspólnego modelu danych państwa.
Mamy pewne zalążki tego modelu w Krajowych Ramach Interoperacyjności oraz rejestry, które się z
tym wiążą. Podobnie w ePUAP są opublikowane struktury atomowe. Jest to nadal zbyt mało, aby
zachować referencje i interoperacyjność.
Cele szczegółowe:
 Zwiększenie samej podaży oczekiwanych przez społeczeństwo usług transakcyjnych,
rozumianych jako automatyzacja procesu, tak aby zmniejszyć zaangażowanie Obywatela.
Można te usługi nazwać ze względu na dojrzałość „kooperacyjne”, ale znane się w
nomenklaturze unijnej jako „transakcyjne”.
 Zwiększenie poziomu wykorzystania tj. popytu na te usługi. Obecnie dostrzegana jest mała
chęć do korzystania z tych usług.
 Usprawnienie procesów wewnątrzadministracyjnych. Nie chodzi więc o usprawnianie
komunikacji Obywatela lecz administracji samej w sobie.
Mówimy tu o wsparciu wewnętrznych procesów na potrzeby realizacji zadań, tak by były
bardziej przyjazne dla odbiorców.
 Zapewnienie warunków do współpracy i efektywnej wymiany danych z rejestrów.
 Zidentyfikowanie, uproszczenie i automatyzacja procedur dostępu do informacji i danych
rejestrowych.
 Redukcja kosztów i czasu przyłączenia „nowych” rejestrów.
Potrzeby klientów usług:
1. W obszarze spójności informacyjnej zasobów uznajemy, że sytuacją AS IS jest infrastruktura
resortowa i silowowa (nie systemów informatycznych lecz zadań w Państwie); skutkiem jest
brak spójności zasobów informacyjnych.
Zatem TO BE wyobrażamy sobie, że po wdrożeniu modelu referencyjnego, wszyscy się
zgodzimy jak komunikacja powinna wyglądać – rozmowy wewnątrz administracji są bardzo
zaawansowane w tym zakresie, włącznie z wykonaniem prac dyplomowych w tym zakresie.
2. Dostępność informacji – AS IS zakłada, że powinna być realizacja KPA art. 220 oraz kultura
oświadczeń, jednak obecnie nawet jeśli urząd niższego szczebla chciałby korzystać z tych
danych, to nie jest możliwe w wyniku różnych uwarunkowań organizacyjnych.
Wyobrażamy sobie – TO BE, że nastąpi reedukacja nadmiernej redundancji oraz że będzie API
do systemów dziedzinowych, udostępniane dane za zgodą lub na wniosek klienta / danego
organu.
1/7
3. W zakresie jakości informacyjnej zasobów – AS IS występują bariery technologiczne dostępu
do systemów, w ramach projektu chcemy się z nią zmierzyć i TO BE poprzez szynę i wspólne
środowisko poprawić usługę dostępu do danych i rozliczalności – chcielibyśmy dać
Obywatelom informację, kto kiedy i po co miał dostęp do moich danych.
Przyjęliśmy nazwę że jest to Krajowa Szyna Usług, a tak naprawdę chodzi o dane.
Usługi realizowane w ramach projektu to:
a) Usługa integracji – usługa integracji rejestrów i systemów dziedzinowych jak i podłączanie
nowych rejestrów/systemów
b) Zarządzanie dostępem do szyny
c) Usługi monitorowania efektywności, wydajności i bezpieczeństwa wymienianych informacji
d) Spójny model danych w interoperacyjnym modelu informacyjnym
Nie będzie to zamrożony model, ani jedna baza danych, natomiast po stworzeniu tego
modelu będziemy wiedzieli, z których innych rejestrów możemy inny odtworzyć.
Redundancja zostanie, ale nadmiarowość zostanie usunięta – będzie oznaczone, że dane
pochodzą z danego źródła. Dane referencyjne będą zesłownikowane.
Usprawnienie procesów:
 Udostępniania danych, zarówno wewnątrz administracji jak i na zewnątrz wg ustawowych
delegacji
 Integracja umożliwiająca wymianę danych, tak żeby przełamać barierę wchodzenia we
wspólną komunikację
 Pozyskiwania informacji w celu szybszej obsługi obywatela/przedsiębiorcy
 Aktualizacji danych dzięki określeniu rejestrów referencyjnych
Będziemy chcieli obsłużyć proces z chwilą gdy obowiązek meldunkowy zostanie zniesiony, tj.
gdy ma miejsce komunikacja z PESEL, to będąc np. w ZUS wykonując inną czynność, to
możemy w procesie w ZUS poprosić o aktualizację adresowych danych referencyjnych.
Korzyści:
 Grupa usprawnienia działania administracji:
– procesów wewnętrznych przyspieszających realizację zadań
– ułatwienie powszechnego korzystania z zasobów informacyjnych
– redukcji liczby błędów wynikającej z automatyzacji przetwarzania danych

Redukcja kosztów rozumiana jako czas i pieniądz związana z podłączeniem nowego
rejestru/systemu dziedzinowego
Zmiany prawne:
 Nie ma potrzeby wprowadzania bezpośrednich zmian w prawie.
 Natomiast gdy pojawią się możliwości techniczne, to właściciele rejestrów mogą
zidentyfikować pewien zakres zmian „lex specialis” w celu usprawnienia komunikacji.
2/7
Podstawy prawne:
1. Ustawa z dn. 17 lutego 2005 o informatyzacji działalności podmiotów realizujących zadania
publiczne
2. Ustawa z dn. 14 czerwca 1960 Kodeks Postępowania Administracyjnego, art. 220
3. Ustawa z dn. 2 lipca 2004 r. o swobodzie działalności gospodarczej, art. 22e
4. Rozporządzenie Ministra do spraw Administracji i Cyfryzacji z dn. 6 maja 2014 r. w sprawie
zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej
5. Rozporządzenie Rady Ministrów z dn. 12 kwietnia 2012 r. w sprawie Krajowych Ram
Interoperacyjności
Interesariusze:
 Bezpośrednim, czyli operatorem jest MAiC, co wynika z roli ustawy o działach, ale też w
wyniku tego, że prowadzimy nadzór nad wojewodami a przez nich nad gminami
 Pośredni – gestorzy rejestrów i systemów dziedzinowych
 Wykonawca – CPI
 Zaangażowani – Gestorzy oraz organy realizujące procedury administracyjne
Zapomnieliśmy zaś o Dostawcach systemów informatycznych, którzy to API wdrożą. Zostaną oni
dodani do prezentacji przed przekazaniem.
Dalszą część prezentacji poprowadziła Pani Katarzyna Koszalska:
Jeżeli chodzi o dane pobierane i przekazywane są to dane z rejestrów i systemów dziedzinowych.
Wybraliśmy na realizację tego projektu główne rejestry i systemy dziedzinowe. Oraz te ministerstwa,
w których siatka połączeń jest największa. GUGIK, GUS, MSW, USDC, MF, MS, ZUS, MAiC i MEN.
W zakresie tych gestorów rejestrów i systemów dziedzinowych chcemy się skupić nad realizacją tego
projektu, docelowo myśląc o wszystkich. Jeśli chodzi dane przekazywane to będą to szyfrowane dane
z rejestrów i systemów dziedzinowych również w zakresie orkiestracji procesów na szynie.
Architektura:
Dotychczasowy rozwój usług publicznych oparty jest na modelu silosowym, w którym każdy resort i
urząd administracji centralnej autonomicznie rozwija usługi, a swoje potrzeby informacyjne zaspokaja
poprzez bezpośrednią wymianę danych z rejestrami referencyjnymi Państwa i systemami
dziedzinowymi innych resortów w oparciu o model peer-to-peer.
Projekt HELIOS zachowując autonomiczność resortów, zmieni ten model a komunikacja
międzyresortowa - pomiędzy wszystkimi systemami dziedzinowymi i rejestrami referencyjnymi
odbywać się będzie z wykorzystaniem pośrednika – Krajowej Szyny Usług (KSU).
Ze względu na autonomię prawno-kompetencyjną, finansową i organizacyjną jednostek rządowych (i
samorządowych) rezygnacja z tego modelu jest praktycznie niemożliwa.
W związku z tym niezbędny jest takie zaprojektowanie architektury informacyjnej państwa, która po
pierwsze zachowa autonomiczność działań poszczególnych rejestrów i systemów a po drugie
umożliwi ponadresortowe myślenie o zadaniach realizowanych przez poszczególne jednostki
administracji państwowej.
3/7
W projekcie zaproponowano taki model architektury, który pozwoli na autonomiczną pracę
i utrzymanie systemów resortowych pod ich kontrolą i jednocześnie uprości i sformalizuje procesy
komunikacji między resortami, dostarczając bezpiecznego i efektywnego pośrednika w postaci
Krajowej Szyny Usług, który zapewni spójność semantyczną, prawną, organizacyjną i techniczną
wymienianych danych. Jest to model federacyjny.
W zakresie KSU zostaną udostępnione takie funkcjonalności oraz moduły jak:







Oprogramowanie wspomagające budowanie procesów na KSU składające się z platformy
wykonawczej i rozwojowej.
Oprogramowanie zarządzające kolejnością przetwarzania komunikatów na KSU.
Moduł monitorujący procesy na KSU.
Rozwiązanie zapewniające sterowanie przepływami informacji w ramach infrastruktury KSU.
Moduł wspomagający zarządzanie KSU.
Moduł identyfikacji nadużyć.
Szyfrowanie – moduł zapewniający poufność treści wiadomości wymienianych przez KSU.
Wykorzystane składniki – szyny resortowe oraz istniejące sieci administracji publicznej.
Interfejsy – Interfejsy do rejestrów oraz systemów wchodzących w zakres projektu.
Budżet:
Elementy składowe takie jak na poprzedniej prezentacji wg wytycznych POPC, natomiast całkowity
koszt wytworzenia to 56 mln, roczny koszt to 3 mln zl.
W drugiej kolumnie tabeli podobnie jak poprzednio jest błąd dotyczący przedstawienia kwot w mln.
Powinno być w tyś. i zostanie to poprawione przed przekazaniem prezentacji.
Harmonogram ramowy dzielimy na dwie fazy:
Faza pilotaż – analiza
1. Konsultacje z gestorami rejestrów
2. Analiza wymagań (systemowych, technicznych, funkcjonalnych) Krajowej Szyny Usług
3. Specyfikacja procesów przepływów danych pomiędzy rejestrami oraz systemami
dziedzinowymi
4. Specyfikacja procesów powiązanych z Krajową Szyną Usług
5. Identyfikacja i specyfikacja usług publikowanych na Krajowej Szynie Usług
6. Opracowanie procedury wymiany danych z wykorzystaniem Krajowej Szyny Usług
7. Tworzenie Kanonicznego Modelu Danych
8. Katalog referencyjnych rejestrów oraz systemów dziedzinowych
9. Przygotowanie dokumentacji przetargowej
Faza realizacji
1. Uruchomienie i konfiguracja sprzętu
2. Uruchomienie i pilotaż pierwszych 4 rejestrów: MSW, GUGiK, GUS (Grupa1)
4/7

Prace analityczne niezbędne do włączenia konkretnych systemów przeprowadzone
zgodnie z procesem SOMA
 Prace programistyczne w zakresie integracji
 Uruchomienie i konfiguracja w środowisku projektowym
 Testy
 Odbiór
3. Podłączenie do Krajowej Szyny Usług kolejnej grupy rejestrów: MF, MG, ZUS (Grupa 2)
 Prace analityczne niezbędne do włączenia konkretnych systemów przeprowadzone
zgodnie z procesem SOMA
 Prace programistyczne w zakresie integracji
 Uruchomienie i konfiguracja w środowisku projektowym
 Testy
 Odbiór
4. Podłączenie i uruchomienie do Krajowej Szyny Usług - MS, MAiC, MZ, MEN (Grupa 3)
 Prace analityczne niezbędne do włączenia konkretnych systemów przeprowadzone
zgodnie z procesem SOMA
 Prace programistyczne w zakresie integracji
 Uruchomienie i konfiguracja w środowisku projektowym
 Testy
 Odbiór
5. Produkcyjne uruchomienie Krajowej Szyny Usług
6. Stabilizacja
Rozpoczęcie projektu planowane na ostatni kwartał 2015 uzależnione jest od daty uzyskania
dofinansowania.
Harmonogram przetargów:
1. Przetarg na zakup usług wspomagających przygotowanie projektu
2. Przetarg na dostawę oprogramowania dla zespołu projektowego
3. Przetarg na zakup sprzętu informatycznego i oprogramowania do Krajowej Szyny Usług
4. Przetarg na zapewnienie fizycznego połączenia pomiędzy ośrodkami podstawowym i
zapasowym
5. Przetarg na zapewnienie fizycznego połączenia KSU z wybranymi podmiotami
odpowiedzialnymi za utrzymanie rejestrów/systemów dziedzinowych.
W tym momencie przejął prowadzeni Dyrektor Christow i rozpoczął etap pytań i odpowiedzi
Pytanie Przedstawiciela CA Consulting - Pan Igor Bednarski:
Przedstawiciel poinformował o dwóch tematach, które chciałby poruszyć. Jeden element stricte
techniczny, drugi organizacyjny, o którym nie było mowy podczas prezentacji.
Czy w ramach projektu planowane jest zapewnienie dostępności do poszczególnych usług?
W prezentacji była mowa o Krajowej Szyny Usług. Jak mają się do tego produkty realizowane w
ramach projektu ePUAP2, gdzie były realizowane mechanizmy Krajowej Szyny Usług.
Odpowiedź Katarzyna Kosmalska CPI:
Faktycznie powinno się pojawić na prezentacji, że zamierzamy rozwijać ePUAP2 gdyż jest to w
planach. Przeanalizowaliśmy elementy rozwijane obecnie z dostawcami zewnętrznymi w ramach
ePUAP2. W projekcie planujemy wykorzystać infrastrukturę ePUAP2 oraz elementy funkcjonalne
zrealizowane w ramach projektu. Jednak nasze działania są rozwojem i uzupełnieniem platformy
ePUAP a nie powieleniem już zrealizowanych elementów.
5/7
Odpowiedź Dyrektora Christow’a:
Robimy reuse składników, które już są w ePUAP2, natomiast po analizie stwierdziliśmy, że nie ma w
projekcie ePUAP2 składników spełniających zadania orkiestracji międzyresortowych. Tak naprawdę
ten element jest zaznaczony w projekcie pod hasłem dostępu do rejestrów.
Pytanie Przedstawiciela CA Consulting - Pan Igor Bednarski:
Dostęp do rejestru jest tak długi jak informatyzacja. Czy prace nad dostępem do rejestrów są również
sprawdzone od strony organizacyjnej, czy były już prowadzone uzgodnienia międzyresortowe?
Odpowiedź Dyrektora Christow’a:
Tryby ustawowe dostępów są przeróżne: na podstawie decyzja, na wniosek, za pośrednictwem i
zgodą Obywatela. Katalog usług dostępowych będzie organizacyjnie przygotowany, co nie zmienia
faktu, ze warto przygotować środowisko, aby resorty się wzajemnie widziały. Projekt ma na celu
przede wszystkim wystawienie wspólnego punktu, poprzez który będzie dostęp do rejestrów.
Pytanie Przedstawiciela Polskiej Izby Informatyki i Komunikacji – Pana Wiesława Paluszyńskiego:
Pierwszą próbą takiego punktu było „Źródło” i dotyczyło integracji systemów. Czy były próby
wykorzystania tego?
Odpowiedź Dyrektora Christow’a:
Widzimy wyniki i mamy przemyślenia w zakresie aplikacji „Źródło”. MSW robiąc rejestr PESEL i
system BUSC, dało bezpieczny dostęp poprzez sieć OST 112, już się pojawiły postulaty aby do tego
punktu można było podłączyć inne systemy. Problem jaki się pojawia powiązany jest z aspektem
organizacyjnym. MSW realizuje tylko część procesów związanych z obywatelem, na przykład
dotyczących dowodów osobistych, ale nie jest w stanie zrealizować całego procesu wymiany
informacji miedzy rejestrami.
Pytanie Przedstawiciela Polskiej Izby Informatyki i Komunikacji – Pana Wiesława Paluszyńskiego:
A co z bezpieczeństwem? Całe mechanizmy bezpieczeństwa i orkiestracja bezpieczeństwa musi być
oparta na e-identyfikacji po stronie A2A i będzie wymagać silnych narzędzi po stronie rozliczalności.
Wydaje się, że projekt jest niedoszacowany z punktu widzenia kosztów tego projektu. Przy tego typu
architekturze, będą zapytania o charakterze niejawnym. W związku z czym jest cala kategoria
przypadków łączenia danych, które w jakimś zakresie musza być analizowane pod tym kątem.
Podobnie było przy projekcie „ZMOKU”. Należy uwzględnić, że jest tu wiele danych wrażliwych,
danych MSW, danych zdrowotnych, danych osobowych. Zakładam, że system z założenia nie
przechowuje danych?
Odpowiedź Dyrektora Christow’a:
Tak, system nie przechowuje danych. Są pewne rozwiązania z modelem proxy, które można
podłączyć do systemu. Prośba do Kolegów aby w Studium przeanalizować kwestię kosztów.
Zagadnienie bezpieczeństwa jest oczywiście brane pod uwagę ale nie planujemy przekazywania
danych niejawnych.
Kontynuacja pytania:
Przykładowa informacja: podaj mi wszystkich Kowalskich w promieniu 10 km, jest już informacją
niejawną. System może zawierać dane jawne, ale przy tym poziomie wykorzystania danych z
rejestrów, trzeba się z tym liczyć, że pewne zapytania mogą dotyczyć danych o charakterze
niejawnym.
Pytanie przedstawiciela SAS Institute – Pana Marcina Piotrowskiego:
6/7
Ja zakładam, że system nie przechowuje danych. Jeżeli odpytamy o Jana Kowalskiego ze wszystkich
rejestrów, to odpowiedzi mogą być ciekawe. Zagadnienie metadanych tych rejestrów, czy Państwo
się nad tym zastanawiali?
Odpowiedź Dyrektora Christow’a:
Na poziomie metadanych jest Obywatel, Adres, Podmiot i to wszystkie na poziomie
interoperacyjności. Koledzy z GUS przygotowali na podstawie statystyk ścieżkę życia danych
Obywatela, od punktu narodzin do punktu archiwizacji. W ogóle nie mówimy o elementach zapytań
zbieżnych do rejestru. Nie ma czegoś takiego, że mogę zadawać zapytanie po rejestrach. Takich usług
w ogóle nie będzie.
Kwestie referencyjności na przykładzie Adresów. Wiele systemów ma słownik adresów. Natomiast
sam gestor rejestru nadpisuje dane jeżeli nastąpi zmiana. Czyli pojawia się problem, że na wniosek
Obywatela, należy nadpisać dane. Ale można sobie wyobrazić model, w którym Obywatel z każdego
miejsca może zgłosić potrzebę zmiany danych z pośrednictwem urzędu w którym właśnie się
znajduje.
Na tym sesję pytań i odpowiedzi zakończono. Dyrektor Christow podziękował Gościom i tym samym
zakończył prezentacje.
7/7