Portal Interoperacyjności
i Architektury

Zagadnienia przedstawione w tym dokumencie powinny być wzięte pod uwagę po zapadnięciu decyzji odnośnie stworzenia lub modyfikacji systemu teleinformatycznego. W opracowaniu przyjęto, że zostały już ustalone cele stawiane przed projektem tworzącym lub modyfikującym system, zidentyfikowani zostali interesariusze i przeprowadzono analizę biznesową. 

Niektóre z poruszanych zagadnień będą i powinny być rozważane przed podjęciem decyzji o budowie lub modyfikacji systemu, natomiast powinny one być rozważone ponownie, kiedy jest już bardziej sprecyzowany zakres realizowanego projektu. 
 

Budując system teleinformatyczny w podmiocie realizującym zadania publiczne należy zwrócić uwagę na cztery zagadnienia płynących z regulacji prawnych:

• Umocowanie podmiotu do stworzenia planowanego systemu lub realizacji w nim zmian;
• Umocowanie podmiotu, który będzie korzystał z systemu, do realizacji zadań publicznych za pomocą tworzonego lub modyfikowanego systemu teleinformatycznego i/lub rejestru publicznego;
• Wymagania funkcjonalne i pozafunkcjonalne określone dla systemu teleinformatycznego lub rejestru tworzonego w tym systemie zawarte w dziedzinowych regulacjach prawnych;
• Uniwersalne wymagania biznesowe i techniczne określone dla systemów teleinformatycznych oraz rejestrów publicznych w sektorze publicznym.

a. Umocowanie podmiotu do stworzenia planowanego systemu lub realizacji w nim zmian

Należy zweryfikować, czy podmiot realizujący projekt budowy lub zmiany systemu teleinformatycznego i/lub rejestru publicznego jest umocowany w przepisach prawa do realizacji takich działań w ramach przypisanych mu zadań publicznych.

b. Umocowanie podmiotu, który będzie korzystał z systemu, do realizacji zadań publicznych za pomocą tworzonego lub modyfikowanego systemu teleinformatycznego i/lub rejestru publicznego

Należy zweryfikować, czy zadania podmiotu, który będzie korzystał z systemu teleinformatycznego i/lub rejestru publicznego, mogą być realizowane przy wykorzystaniu tego systemu i/lub rejestru. W szczególności należy zweryfikować, czy przepisy prawa - przez określenie specyficznych zapisów - nie wykluczają realizacji tych zadań przy wykorzystaniu systemów teleinformatycznych oraz rejestrów publicznych. W przypadku, gdy przepisy prawa nie pozwalają realizować określonych zadań za pomocą systemów teleinformatycznych, należy przeprowadzić analizę możliwości i zasadności przygotowania zmian legislacyjnych (zgodnie z zasadą „kontakt domyślnie cyfrowy”).

c. Wymagania funkcjonalne i pozafunkcjonalne określone dla systemu teleinformatycznego lub rejestru tworzonego w tym systemie zawarte w dziedzinowych regulacjach prawnych

Podczas projektowania nowego systemu lub zmian w systemie należy spełnić wszystkie wymagania określone dla tego systemu lub rejestru wskazane w przepisach prawa odnoszących się do zadania publicznego, którego realizacja jest wspierana przez system lub rejestr.

d. Uniwersalne wymagania biznesowe i techniczne określone dla systemów teleinformatycznych oraz rejestrów publicznych w sektorze publicznym

Systemy teleinformatyczne oraz rejestry publiczne w sektorze publicznym, poza specyficznymi wymaganiami określonymi dla projektowanego systemu lub rejestru, muszą implementować również uniwersalne wymagania określone dla systemu teleinformatycznych i rejestrów publicznych w przepisach prawa. Podczas projektowania systemu teleinformatycznego i/lub rejestru publicznego należy uwzględnić różne przepisy prawa powszechnego, w szczególności:

• Ustawa z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz.U. Nr 64, poz. 565). Zobacz opis wymagań wynikających z ustawy.
• Rozporządzenie Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (Dz. U. z 2012 r. poz. 526). Zobacz opis wymagań wynikających z rozporządzenia.
• Rozporządzenie Rady Ministrów z dnia 27 września 2005 r. w sprawie sposobu, zakresu i trybu udostępniania danych zgromadzonych w rejestrze publicznym (Dz.U. z 2005 r. poz. 1692).
• Rozporządzenie Prezesa Rady Ministrów z dnia 14 września 2011 r. w sprawie sporządzania pism w formie dokumentów elektronicznych, doręczania dokumentów elektronicznych oraz udostępniania formularzy, wzorów i kopii dokumentów elektronicznych (Dz. U. z 2011 r. poz. 1216).
• Rozporządzenie Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz. U. z 2005 r. poz. 1836).

Należy zweryfikować także wpływ innych aktów prawa na tworzony lub modyfikowany system lub rejestr takich, jak:

• Ustawa z dnia 25 lutego 2016 r. o ponownym wykorzystywaniu informacji sektora publicznego (Dz. U. z 2016 r. poz. 352).
• Ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz. U. z 2019 r. poz. 848).

Pryncypia architektoniczne są zbiorem ogólnych zasad i wytycznych dotyczących tworzenia, wdrażania i wykorzystywania rozwiązań teleinformatycznych. Polskie pryncypia architektoniczne powstały m.in. na podstawie pryncypiów z Europejskich Ram Interoperacyjności (zobacz opis polskich pryncypiów architektonicznych).

W ramach Europejskich Ram Interoperacyjności (ang. European Interoperability Framework, EIF) zostały określone pryncypia, które powinny zostać uwzględnione przez podmioty europejskie realizujące zadania publiczne podczas opracowywania systemów teleinformatycznych. 

Zobacz:

• European Interoperability Framework (EIF), wersja angielska: tekst EIF i opis EIF w języku polskim.
• Europejskie Ramy Interoperacyjności, tłumaczenie dokumentów EIF: tekst EIF w języku polskim.

Wytyczne architektoniczne (ang. architectural drivers) to czynniki, jakie należy wziąć pod uwagę podczas podejmowania decyzji architektonicznych – kształtują one architekturę tworzonych lub modyfikowanych systemów teleinformatycznych. Wytyczne architektoniczne można podzielić na:

• Wymagania funkcjonalne – lista funkcji, jakie system powinien realizować, np. przypadki użycia czy historyjki użytkownika, 
• Atrybuty jakościowe – określają wymagania jakościowe, które system ma spełnić, np. dotyczące skalowalności, bezpieczeństwa, maksymalnego czasu realizacji określonej funkcji w systemie, 
• Ograniczenia projektowe – określają ograniczenia, w jakich będzie realizowany projekt, np. dotyczące budżetu, dostępnych zasobów, czy zgodności z przepisami prawa, 
• Konwencje – określają zasady wykorzystywane w opracowywaniu systemów teleinformatycznych w celu promowania spójnych rozwiązań, np. zastosowanie standardu API, wykorzystanie Węzła Krajowego do uwierzytelnienia obywateli, 
• Cele projektowe – określają jakie narzędzia należy zastosować, żeby zrealizować cele stawiane przed projektem, np. inne rozwiązania mogą zostać wybrane dla realizacji systemu mocno obciążonego, ale planowanego do pracy w okresie kilku miesięcy, a inne dla systemu horyzontalnego, którego trwałość określona jest na kilka lat.

Jednym ze źródeł wytycznych architektonicznych są przepisy prawa.

Dla systemów teleinformatycznych i rejestrów publicznych w administracji publicznej bardzo istotne są wymagania określone: 

• w Ustawie z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (skrót UoI, zobacz opis wymagań wynikających z ustawy) oraz
• w wydanych na jej podstawie rozporządzeniach, w tym w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r. w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych (skrót KRI, zobacz opis wymagań wynikających z rozporządzenia oraz standardy Krajowych Ram Interoperacyjności).

Zgodnie z § 8 ust. 1 KRI systemy teleinformatyczne wykorzystywane do realizacji zadań publicznych budowane są zgodnie z architekturą zorientowaną na usługi.

Podczas projektowania systemu teleinformatycznego lub rejestru publicznego należy mieć na uwadze udostępnianie za pomocą usług API funkcji systemu, które potencjalnie mogą być wykorzystane w przyszłości przez inne rozwiązania (właściciela tego systemu lub innych podmiotów, także niepublicznych). Z przeprowadzonej analizy może wynikać, że funkcjonalność systemu będzie dostępna tylko przez dedykowany interfejs GUI. Należy jednak wziąć pod uwagę, że w przyszłości inne podmioty mogą potrzebować skorzystać z danej funkcjonalności za pomocą usług API. Ich wymaganiem będzie automatyzacja i przyśpieszenie realizacji swoich zadań publicznych, co z drugiej strony może odciążyć też pracowników podmiotu wykorzystującego projektowany system. Jeżeli planowana architektura opracowywanego rozwiązania uwzględni takie potencjalne wykorzystanie systemu za pomocą usług API, to w przyszłości łatwiejsze będzie wdrożenie zmian udostępniających takie usługi, bez ponoszenia dużych dodatkowych kosztów na etapie projektowania rozwiązania (zadbanie o odpowiednią modularność systemu), jak i w przyszłości.

Podczas planowania lub modyfikacji systemu bądź rejestru należy tak zaprojektować usługi API, aby w przyszłości inne podmioty mogły łatwo skorzystać z takich usług. Zaplanowanie na wczesnym etapie odpowiedniego modelu zarządzania dostępem do danych (na poziomie organizacyjnym i technicznym) pozwoli na wykorzystanie tych samych elementów systemu do zapewnienia dostępu do danych różnym podmiotom, zgodnie z przysługującymi im uprawnieniami. 

Powyższe zalecenia wynikają m.in. z zapisów § 12 KRI: „Określając funkcjonalność rejestrów publicznych oraz systemów teleinformatycznych, uwzględnia się potrzebę zapewnienia podmiotom uprawnionym realizacji zadań wynikających z odrębnych przepisów” oraz art. 15 (dotyczącego nieodpłatnego dostępu do danych) i art. 15a (dotyczącego udostępniania danych) UoI.

Zgodnie art. 13 ust. 2 pkt 2a UoI, podmiot publiczny realizujący zadania publiczne przy wykorzystaniu systemu teleinformatycznego albo z użyciem środków komunikacji elektronicznej do przekazywania danych pomiędzy tym podmiotem a podmiotem niebędącym organem administracji rządowej, publikuje w Biuletynie Informacji Publicznej lub udostępnia w inny sposób, zestawienie stosowanych w oprogramowaniu interfejsowym systemu teleinformatycznego używanego przez ten podmiot do realizacji zadań publicznych struktur dokumentów elektronicznych, formatów danych oraz protokołów komunikacyjnych i szyfrujących.

W przypadku udostępniania usług sieciowych opartych o standardy WS-* (zobacz opis usług sieciowych w Wikipedii), zgodnie z § 8 pkt. 2 i 3 KRI do opisu usług sieciowych należy skorzystać ze standardu Web Services Description Language (WSDL) (zobacz opis WSDL na stronie W3C) oraz udostępnić w repozytorium interoperacyjności. 

W przypadku udostępniania usług sieciowych opartych o REST (zobacz opis REST w Wikipedii) ze względu, że standardu WSDL nie stosuje się do opisu tego typu usług, zalecane jest zastosowanie powszechnie wykorzystywanego standardu OpenAPI i udostępnienie go w repozytorium interoperacyjności. Standard OpenAPI dla usług REST, analogicznie jak standard WSDL dla usług WS-*, jest powszechnie uznanym i stosowanym opisem dla usług sieciowych, a pozwala na opis usługi na jeszcze wyższym poziomie. 

Zgodnie z art. 16 UoI, podmiot publiczny, organizując przetwarzanie danych w systemie teleinformatycznym, jest obowiązany zapewnić możliwość przekazywania danych również w postaci elektronicznej przez wymianę dokumentów elektronicznych związanych z załatwianiem spraw należących do jego zakresu działania, wykorzystując informatyczne nośniki danych lub środki komunikacji elektronicznej. Dodatkowo podmiot publiczny jest zobowiązany udostępnić elektroniczną skrzynką podawczą, wykorzystywaną do przesyłania dokumentów elektronicznych kierowanych do podmiotu oraz prowadzić wymianę informacji w postacie elektronicznej. 

Podczas projektowania nowego lub modyfikacji systemu teleinformatycznego należy przeanalizować możliwość, czy też zasadność implementacji automatycznej wymiany dokumentów elektronicznych oraz generowania dokumentów elektronicznych zgodnych z odpowiednimi wzorami dokumentów.  Zgodnie z art. 16a ust. 1 pkt. 3 UoI, jeżeli przepisy nie wykluczają przesyłania dokumentów drogą elektroniczną, to organ odpowiedzialny w przepisach prawa za określenie wzoru dokumentu, udostępnia na ePUAP lub w innym systemie teleinformatycznym formularz elektroniczny umożliwiający wygenerowanie dokumentu elektronicznego w celu złożenia go za pomocą środków komunikacji elektronicznej.

W przypadku obsługi w systemie teleinformatycznym dokumentów i podpisów elektronicznych, należy zapewnić możliwość składania i weryfikacji następujących podpisów elektronicznych:

• Podpisu elektronicznego weryfikowanego certyfikatem kwalifikowanym [art. 19 ustawy z dnia 5 września 2016 r. o usługach zaufania oraz identyfikacji elektronicznej (Dz. U. z 2016 r. poz. 1579)];
• Podpisu zaufanego (art. 20ae UoI);
• Podpisu osobistego [art. 12d ust. 1 ustawy z dnia 6 sierpnia 2010 r. o dowodach osobistych (Dz. U. z 2020 r. poz. 332, 695, 875, 1517, 2320)].

Zgodnie z art. 16a ust. 1 pkt 1 i 2 UoI, jeżeli w przepisach prawa został wskazany organ właściwy do określenia wzoru dokumentu i jeżeli przepisy te nie wykluczają przesyłania dokumentów drogą elektroniczną, organ ten przekazuje ministrowi właściwemu do spraw informatyzacji wzór dokumentu elektronicznego w celu umieszczenia go w Centralnym Repozytorium Wzorów Dokumentów Elektronicznych (CRWDE) oraz opis usługi możliwej do zrealizowania przy wykorzystaniu wzoru dokumentu elektronicznego w celu zamieszczenia go w katalogu usług.

W przypadku, gdy tworzony lub modyfikowany system teleinformatyczny udostępnia usługi pozwalające na przesyłanie danych z/do tego systemu, to zgodnie z art. 21 UoI przeprowadza się badanie poprawności wdrożenia rozwiązań dotyczących usług przesyłania danych, przy wykorzystaniu testów akceptacyjnych.

Zgodnie z art. 13 ust. 2 pkt 2b UoI, podmiot publiczny, który wykorzystuje system teleinformatyczny do realizacji zadań publicznych (do przekazywania danych pomiędzy tym podmiotem a podmiotem niebędącym organem administracji rządowej), jest zobowiązany do udostępnienia testów akceptacyjnych dla tego typu usług. Testy akceptacyjne rozumiane są jako udokumentowane wartości danych wejściowych wprowadzanych do systemu teleinformatycznego i powiązanych z nimi wartości oczekiwanych danych wyjściowych, opisujące zestawy poprawnych odpowiedzi systemu teleinformatycznego na podawane dane wejściowe, pozwalające na sprawdzenie poprawności wdrożenia oprogramowania interfejsowego.

Podmiot publiczny może nie udostępniać testów akceptacyjnych, jeżeli w oprogramowaniu interfejsowym mają być stosowane wyłącznie formaty danych oraz protokoły komunikacyjne i szyfrujące określone w KRI (art. 13 ust. 4 UoI) lub podmiot publiczny udostępnił system testowy (art. 21 ust. 5b UoI). 

Podmiot publiczny może udostępnić testowy system teleinformatyczny, funkcjonalnie odpowiadający systemowi produkcyjnemu, w celu dokonywania sprawdzenia poprawności wdrożenia rozwiązań pod względem organizacyjnym, semantycznym i technologicznym (art. 21 ust. 5a UoI).

Na podstawie art. 24 UoI nie ma obowiązku stosowania badania poprawności wdrożenia opisanego powyżej, jeżeli w oprogramowaniu interfejsowym mają być stosowane wyłącznie formaty danych oraz protokoły komunikacyjne i szyfrujące określone w KRI, chyba że:

• podmiot publiczny udostępnił testy akceptacyjne;
• twórca oprogramowania interfejsowego albo inny podmiot posiadający autorskie prawa majątkowe do oprogramowania interfejsowego, które ma być wykorzystywane do realizacji zadania publicznego, wystąpił o udostępnienie testów akceptacyjnych w celu przeprowadzenia badania;
• podmiot publiczny udostępnił system testowy.

Więcej informacji odnośnie testów akceptacyjnych i badania poprawności wdrożenia można znaleźć we wskazanych powyżej przepisach i Rozporządzeniu Ministra Nauki i Informatyzacji z dnia 19 października 2005 r. w sprawie testów akceptacyjnych oraz badania oprogramowania interfejsowego i weryfikacji tego badania (Dz. U. z 2005 r. poz. 1836).

W § 10 ust. 1 KRI wyszczególnione zostały typy obiektów odpowiadające osobom fizycznym, podmiotom i obiektom przestrzennym. 

Podmioty realizujące zadania publiczne z wykorzystaniem wymiany informacji za pomocą środków komunikacji elektronicznej lub za pomocą dokumentów elektronicznych, w których mają zastosowanie te wyszczególnione typy obiektów, stosują strukturę danych cech informacyjnych tych obiektów zgodną ze strukturą publikowaną przez ministra właściwego do spraw informatyzacji w postaci schematów XML w Repozytorium interoperacyjności (§ 10 ust. 6 KRI). Jeżeli z przepisów prawa wynika, że stosuje się podzbiór cech informacyjnych obiektu, o którym mowa w ust. 1, to zachowuje się typy i zakresy danych określone w schemacie (§ 10 ust. 8 KRI). 

Organ władzy publicznej, prowadzący rejestr publiczny zawierający obiekty innego typu, niż wyszczególnione na początku sekcji, wnioskuje do ministra właściwego do spraw informatyzacji o opublikowanie w repozytorium interoperacyjności schematu XML struktur danych cech informacyjnych tych obiektów.

Zgodnie z art. 14 UoI w przypadku, gdy organ administracji rządowej, organ kontroli państwowej i ochrony prawa, sąd, jednostka organizacyjna prokuratury, jednostka samorządu terytorialnego lub jej organ, ZUS, KRUS, NFZ, prowadzi rejestr publiczny przy użyciu systemów teleinformatycznych, dokonuje uprzedniej weryfikacji danych wprowadzanych po raz pierwszy do tego rejestru pod względem zgodności tych danych z danymi zgromadzonymi w rejestrze PESEL.

W przypadku negatywnego wyniku weryfikacji, podmiot prowadzący rejestr publiczny niezwłocznie przekazuje właściwemu organowi wskazanemu w art. 10 ust. 1 ustawy z dnia 24 września 2010 r. o ewidencji ludności informację o negatywnym wyniku weryfikacji oraz posiadane dokumenty stanowiące podstawę stwierdzenia wskazanej niezgodności, ich uwierzytelnione kopie lub odpisy, chyba że przepisy ustaw odrębnych uniemożliwiają ich przekazanie.

Zgodnie z § 11 KRI podmiot publiczny prowadzący rejestr publiczny, udostępniając dane z tego rejestru jest zobowiązany zapewnić rozliczalność takiej operacji. Z drugiej strony podmiot, który pobiera dane z rejestru publicznego, jest obowiązany do ochrony tych danych na poziomie nie mniejszym niż ten, który ma zastosowanie w rejestrze źródłowym. 

W przypadku, gdy rejestry publiczne wymieniają dane między sobą, to zgodnie z § 13 KRI, powinny być wymieniane tylko informacje niezbędne do prawidłowego funkcjonowania tych rejestrów, a wymiana danych odbywa się przez bezpośrednie odwołanie się do danych referencyjnych przez rejestr inicjujący wymianę. Dane referencyjne to dane opisujące cechę informacyjną obiektu pierwotnie wprowadzone do rejestru publicznego w wyniku określonego zdarzenia, z domniemania opatrzone atrybutem autentyczności.

Jeśli wymiana danych w trybie bezpośrednich odwołań do rejestrów przechowujących dane referencyjne jest niemożliwa lub znacznie utrudniona, dopuszcza się wymianę danych w innym trybie, w tym przez kopiowanie danych przez rejestr inicjujący wymianę.

§ 21 KRI określa w jaki sposób należy zapewnić rozliczalność operacji za pomocą elektronicznych zapisów w dziennikach systemów (logach). Obligatoryjnie należy odnotować działania użytkowników lub obiektów systemowych polegające na dostępie do:

• systemu z uprawnieniami administracyjnymi;
• konfiguracji systemu, w tym konfiguracji zabezpieczeń;
• przetwarzanych w systemach danych podlegających prawnej ochronie w zakresie wymaganym przepisami prawa.

Dodatkowo mogą być odnotowywane działania użytkowników lub obiektów systemowych, a także inne zdarzenia związane z eksploatacją systemu w postaci:

• działań użytkowników nieposiadających uprawnień administracyjnych,
• zdarzeń systemowych nieposiadających krytycznego znaczenia dla funkcjonowania systemu,
• zdarzeń i parametrów środowiska, w którym eksploatowany jest system teleinformatyczny

- w zakresie wynikającym z analizy ryzyka.

Logi powinny być przechowywane przez okres wskazany w przepisach dotyczących danego rejestru publicznego lub systemu teleinformatycznego, a w przypadku braku przepisów odrębnych - przez dwa lata.

Rozdział IV KRI określa wiele wymagań i standardów do zastosowania podczas tworzenia lub modyfikowania systemów teleinformatycznych wykorzystywanych przez podmioty do realizacji zadań publicznych.

Wśród obowiązujących standardów znajdują się:

• Opcjonalnie, polskie normy PN-ISO/IEC 20000-1 i PN-ISO/IEC 20000-2, których uwzględnienie wypełnia wymogi określone w § 15 ust. 1 i 2 KRI, które dotyczą wymagań funkcjonalnych i jakościowych w cyklu życia systemów teleinformatycznych, określanych przy zastosowaniu norm oraz uznanych w obrocie profesjonalnym standardów i metodyk, a także zarządzanie usługami w oparciu o udokumentowane procedury;
• Wymiana danych z innymi systemami teleinformatycznymi za pomocą protokołów komunikacyjnych i szyfrujących odbywa się za pomocą rozwiązań sprzętowych i programowych, określonych w obowiązujących przepisach, normach, standardach lub rekomendacjach ustanowionych przez krajową jednostkę normalizacyjną lub jednostkę normalizacyjną Unii Europejskiej. W przypadku, gdy w wymienionych dokumentach nie wskazano rozwiązań do realizacji określonego zagadnienia, stosuje się standardy uznane na poziomie międzynarodowym, w szczególności opracowane przez: Internet Engineering Task Force (IETF) i publikowane w postaci Request For Comments (RFC) oraz World Wide Web Consortium (W3C) i publikowane w postaci W3C Recommendation (REC) - adekwatnie do potrzeb wynikających z realizowanych zadań oraz bieżącego stanu technologii informatycznych;
• Kodowanie znaków w danych przesyłanych pomiędzy systemami teleinformatycznymi odbywa się według standardu Unicode UTF-8, a uzasadnionych przypadkach dopuszcza się kodowanie znaków według standardu Unicode UTF-16, przy czym zastosowanie kodowania UTF-16, nie może negatywnie wpływać na współpracę z systemami teleinformatycznymi używającymi kodowania UTF-8;
• W przypadku systemów wykorzystujących graficzny interfejs użytkownika, należy zapewnić spełnienie przez ten system wymagań Web Content Accessibility Guidelines (WCAG 2.0), z uwzględnieniem poziomu AA, określonych w załączniku nr 4 do KRI. Należy nadmienić, że w przypadku m.in. jednostek sektora finansów publicznych [w rozumieniu przepisów ustawy z dnia 27 sierpnia 2009 r. o finansach publicznych (Dz. U. z 2009 r. poz. 1240)], ustawa z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych (Dz. U. 2019 poz. 848) wprowadza obowiązek stosowania wytycznych WCAG w wersji 2.1.;
• Udostępnianie zasobów informacyjnych przez system teleinformatyczny odbywa się z zastosowaniem co najmniej jednego z formatów danych określonych w załączniku nr 2 do KRI;
• Jeżeli z przepisów szczegółowych albo opublikowanych w repozytorium interoperacyjności schematów XML lub innych wzorów nie wynika inaczej, podmioty realizujące zadania publiczne umożliwiają przyjmowanie dokumentów elektronicznych służących do załatwiania spraw należących do zakresu ich działania w formatach danych określonych w załącznikach nr 2 i 3 KRI.

Standardach wynikające z Krajowych Ram Interoperacyjności zostały szczegółowo omówione w sekcji Standardy KRI.

Podmiot realizujący zadania publiczne opracowuje i ustanawia, wdraża i eksploatuje, monitoruje i przegląda oraz utrzymuje i doskonali system zarządzania bezpieczeństwem informacji zapewniający poufność, dostępność i integralność informacji z uwzględnieniem takich atrybutów, jak autentyczność, rozliczalność, niezaprzeczalność i niezawodność.

Zalecenia i wymagania odnośnie systemu zarządzania bezpieczeństwem informacji określone są w § 20 KRI.

Podczas projektowania nowego systemu teleinformatycznego, bądź zmian w już istniejącym systemie teleinformatycznym, należy przeanalizować już istniejące rozwiązania w administracji publicznej lub dedykowane dla administracji publicznej. Wykorzystanie istniejących rozwiązań pozwoli m.in. na: 

• prostsze udostępnienie skomplikowanej funkcjonalności, 
• obniżenie kosztów i poziomu skomplikowania projektu,
• obniżenie kosztów eksploatacji systemu po wdrożeniu, 
• zwiększenie bezpieczeństwa poprzez zastosowanie sprawdzonych już rozwiązań
• udostępnienie użytkownikom narzędzi, które już znają - co bezpośrednio spowoduje mniejszy próg wejścia do systemu nowych użytkowników. 

Gotowe lub przygotowywane narzędzia teleinformatyczne do wykorzystania w ramach realizowanych projektów określane są pojęciem bloków budowlanych rozwiązań (BBR). Blokiem budowlanym rozwiązań jest zarówno: 

• system, z którym tworzony/modyfikowany system może się integrować;
• system, który może być wykorzystany do świadczenia części funkcjonalności przewidzianej w projekcie, nawet w oderwaniu od tworzonego/modyfikowanego systemu; 
• biblioteka lub moduł, który może być wykorzystany w tworzonym/modyfikowanym systemie.

Na stronie Bloki budowlane rozwiązań została zaprezentowana lista bloków budowlanych rozwiązań do wykorzystania w administracji publicznej. Zaprezentowano zarówno rozwiązania już istniejące, jak i te, które są jeszcze opracowywane. Lista jest otwarta, także zapraszamy do wracania do tej listy. Jeżeli uważają Państwo, że jakieś rozwiązanie powinno się na niej znaleźć, to prosimy o zgłoszenie takiej propozycji.

Przed podjęciem decyzji architektonicznych odnośnie tworzonego lub modyfikowanego systemu teleinformatycznego bądź rejestru publicznego należy zapoznać się z listą Bloków budowlanych rozwiązań.

Jednym ze sposobów identyfikacji bloków budowlanych rozwiązania do wykorzystania w projekcie jest szczegółowa analiza procesów biznesowych dla zadań publicznych wspieranych przez system teleinformatyczny pod kątem zapewnienia przez bloki budowlane rozwiązania realizacji funkcjonalności określonej dla poszczególnych elementów procesu. 

Poniżej zaprezentowano tabelkę pomagającą zidentyfikować bloki budowlane rozwiązań do wykorzystania podczas budowania lub modyfikacji systemu teleinformatycznego bądź rejestru publicznego. 

W ramach administracji publicznej zostały wypracowane narzędzia, które podmioty realizujące zadania publiczne mogą wykorzystać podczas opracowywania swoich systemów teleinformatycznych. Zastosowanie tych narzędzi może w znacznym stopniu ułatwić wdrażanie zmian w tych systemach, zapewni spójne doświadczenia użytkownika z korzystania z systemów podmiotów realizujących zadania publiczne oraz ułatwić zapewnienie interoperacyjności budowanego lub zmienianego rozwiązania.

Standard określa zalecenia dotyczące interfejsu programistycznego aplikacji dostępu do baz danych, które przechowują dane publiczne. Został stworzony z myślą o administracji publicznej, aby udostępniała swoje dane przez API według jednolitego standardu.

Standard jest opisany na stronie Standardy Otwartości Danych. Z jego pełną treścią można zapoznać się na stronie dane.gov.pl (plik PDF).

W ramach planowania i budowy (lub rozbudowy) systemu teleinformatycznego w podmiotach realizujących zadania publiczne należy w ramach projektu uwzględnić działania, które należy zrealizować odpowiednio przed, w trakcie i po zrealizowaniu nowego systemu lub zmian w systemie.

System Inwentaryzacji Systemów Teleinformatycznych (SIST) określony został w Programie Zintegrowanej Informatyzacji Państwa (PZIP) jako system do obsługi Bazy Aktywnych Systemów Informatycznych Administracji. System SIST służy do zbierania informacji o istniejących systemach administracji publicznej i o gromadzonych w nich danych. 

Użytkownicy systemu SIST mają możliwość wprowadzania danych w sposób ciągły. Zgodnie z ustaleniem Rady Ministrów z posiedzenia w dniu 19 lipca 2016 r. powinni to robić co trzy miesiące oraz każdorazowo - w przypadku wprowadzenia zmian do zgłaszanych systemów.

Dane zbierane w SIST służą bezpośrednio ministrowi właściwemu ds, informatyzacji do wsparcia procesów planistycznych oraz założeń programowych Wspólnej Infrastruktury Informatycznej Państwa i Architektury Informacyjnej Państwa. Wyniki Inwentaryzacji SIST są m.in. źródłem aktualnej informacji o funkcjonalnościach realizowanych przez systemy oraz zakresach przetwarzanych danych. Aktualność tych informacji pozwala eliminować powielanie tych samych funkcjonalności przez systemy podmiotów realizujących zadania publiczne, a także wskazuje potencjalne możliwości integracji systemów tych podmiotów, w celu sprawniejszego i bardziej efektywnego realizowania zadań publicznych.