Po co nam Krajowe Ramy Interoperacyjności?

Agendy rządowe muszą współpracować ze sobą. Agendy rządowe powinny również współpracować z samorządem terytorialnym i innymi podmiotami. Powinny być dostępne dla obywateli. Jednym z koniecznych elementów bezproblemowej i wzajemnej komunikacji elektronicznej jest stworzenie „ram współdziałania”. Na fali paneurpejskiej dyskusji, a także dyskusji ogólnoświatowej - w różnych państwach tworzone są „ramy interoperacyjności”. W Polsce mają powstać Krajowe Ramy Interoperacyjności (i to już w kwietniu). Jaki powinien być kształt takiego dokumentu? Czy jest on w ogóle potrzebny? A jeśli tak, to jaką powinien mieć rangę i jakie zaprojektować mechanizmy egzekwowania postulatów znajdujących się w przyjmowanych „ramach”? Jest sporo pytań. Odpowiedź na nie jest o tyle ważna, że toczy się rozgrywka dotycząca standaryzacji protokołów komunikacyjnych, formatów danych, etc. Wciąż niekompatybilność danego rozwiązania stanowi element walki marketingowej (wiem, że zbyt często o tym piszę), a organizacja państwowa jest często istotnym klientem, wpływa też na kształtowanie popytu na określone usługi i produkty (też informatyczne) – stąd warto zabiegać o to, by takie, a nie inne rozwiązania w administracji publicznej były stosowane.

W projekcie Planu Informatyzacji Państwa na lata 2007-2010, który stanie na Radzie Ministrów najprawdopodobniej w przyszłym tygodniu, zapisano w częsci 3 pt. "Działania w zakresie informatyzacji administracji publicznej na rzecz rozwoju społeczeństwa informacyjnego": "Przedłożenie projektu Uchwały RM o ustanowieniu Krajowych Ram Interoperacyjności". Ma się to stać do kwietnia 2007 roku. Rząd ma więc miesiąc na opracowanie projektu uchwały Rady Ministrów wprowadzającej Krajowe Ramy Interoperacyjności.

Art. 93 Konstytucji stwierdza: "Uchwały Rady Ministrów oraz zarządzenia Prezesa Rady Ministrów i ministrów mają charakter wewnętrzny i obowiązują tylko jednostki organizacyjnie podległe organowi wydającemu te akty. Na podstawie art. 87 Konstytucji: "Źródłami powszechnie obowiązującego prawa Rzeczypospolitej Polskiej są: Konstytucja, ustawy, ratyfikowane umowy międzynarodowe oraz rozporządzenia". A więc uchwała RM nie ma mocy powszechnie obowiązującego prawa - ma ograniczny zakres stosowania. Co prawda uchwały i zarządzenia "podlegają kontroli co do ich zgodności z powszechnie obowiązującym prawem", pytanie tylko jaki poziom ogólności postanowień znajdzie się w uchwale Rady Ministrów na temat ram interoperacyjności? Tak czy inaczej - uchwała swą mocą np. nie obejmie działań samorządu terytorialnego, a przecież samorządy są również łakomym kąskiem na mapach działów marketingu poszczególnych graczy na tym rynku. A może nie?

Co się dzieje w temacie "interoperacyjności" na świecie? Trzeba zacząć od repozytorium IDABC Repository of essential eGovernment documentation. W tym miejscu należy odwołać się do dokumentu referencyjnego IDABC: The "European Interoperability Framework for pan-European eGovernment Services", na razie w wersji 1.0 z 2004. O tym dokumencie była mowa w tekście Standardy w egovernment - czy mogę mieć wrażenie manipulacji?. Jaką mają mieć rangę rekomendacje europejskie w sprawie interoperacyjności (współdziałania)? Czy faktycznie mają mieć moc sprawczą, a więc funkcjonować jako narzędzia kreowania polityki w obszarze standaryzacji komunikacji elektronicznej administracji publicznej, czy też może - jak chcą niektórzy: "jako niezobowiązujące do stosowania wskazówki"? Trwają prace nad nową wersją rekomendacji, a w międzyczasie niektóre kraje europejskie wprowadzają własne ramy interoperacyjności. To samo dzieje się w innych częściach świata. Należy tu wymienić:

Dokumenty te mają różną strukturę. Mogą zawierać w sobie historię wprowadzanych zmian. Już z powyższego zestawienia widać, że mogą funkcjonować w różnych wersjach (wersjonowanie ram interoperacyjności). Tłumaczy się to rozwojem nowych technologii. Ma to też pewne konsekwencje dla określenia zasad przyjmowania takich dokumentów jako oficjalne stanowiska administracji publicznej różnych krajów - wiadomo - ustawę ciężko zmienić, im mniej formalnie zaś dokument umocowany, tym sposób jego aktualizacji jest bardziej elastyczny. Wedle szybkiego przeglądu wskazanych wyżej dokumentów wersjonowanie polegało głównie na dodawaniu kolejnych części do istniejących ram interoperacyjności. W Hong Kongu np. zmiany polegały na dodawaniu "przykładów" narzędzi (popularnych przeglądarek hypertekstowych w części "Remarks"), albo aktualizacje wersji standardów przywoływanych w dokumencie (np. zmieniono WS-I Basic Security Profile, z wersji 1.0 na 1.1), czasem też dokonywano doprecyzowania, o jaki konkretnie standard chodzi - tak było w przypadku zmiany z "OpenDocument 1.0" na ".odp (OpenOffice.org v2.0 file format based on OpenDocument 1.0)" - co również skrzętnie odnotowano. Dokumenty czasem zawierają w sobie tabelki z wymienionymi standardami, wskazując ich nazwy i organizacje standaryzacyjne, czasem (co warto odnotować) w tabelach znajdują się wzmianki o rozpoznanych ograniczeniach ("limitation") stosowania danego rozwiązania (tak np. w Malezji).

Zatem - jeszcze raz: dokumenty te mają różną strukturę, różną objętość, różny poziom ogólności i są wydawane przez bardzo różnie umocowane organy (ministerstwa, zespoły międzyresortowe, agencje odpowiedzialne za ICT, etc), co za tym idzie - mają różny poziom oddziaływania. Niektóre z dokumentów udostępnione są pod ścisłym "copyrightem", inne - jak na przykład duńskie ramy interoperacyjności wydano na zasadach jednej z licencji Creative Commons.

Warto zwrócić wagę, że wiele z kwestii znajdujących się w przywołanych wyżej dokumentach regulowanych jest w Polsce (niedoskonałym) rozporządzeniem Rady Ministrów z dnia 11 października 2005 r. w sprawie minimalnych wymagań dla systemów teleinformatycznych, wydanym na podstawie art. 18 pkt 1 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne. Delegacja do wydania tego rozporządzenia ma następującą postać:

Art. 18. Rada Ministrów, na wniosek ministra właściwego do spraw informatyzacji, określi w drodze rozporządzenia:

1) minimalne wymagania dla systemów teleinformatycznych, mając na uwadze konieczność zapewnienia:

a) spójności działania systemów teleinformatycznych używanych do realizacji zadań publicznych poprzez określenie co najmniej specyfikacji formatów danych oraz protokołów komunikacyjnych i szyfrujących, które mają być stosowane w oprogramowaniu interfejsowym, przy zachowaniu możliwości nieodpłatnego wykorzystania tych specyfikacji,

b) sprawnej i bezpiecznej wymiany informacji w formie elektronicznej między podmiotami publicznymi oraz między podmiotami publicznymi a organami innych państw lub organizacji międzynarodowych

- z uwzględnieniem Polskich Norm oraz innych dokumentów normalizacyjnych zatwierdzonych przez krajową jednostkę normalizacyjną, zachowując zasadę równego traktowania różnych rozwiązań informatycznych;

2) minimalne wymagania dla rejestrów publicznych i wymiany informacji w formie elektronicznej, uwzględniając konieczność zachowania spójności prowadzenia rejestrów publicznych i wymiany informacji w formie elektronicznej z podmiotami publicznymi.

Wydane na podstawie powyższej delegacji ustawowej rozporządzenie spotkało się z pewnymi problemami interpretacyjnymi (por. Pytania do minimalnych wymagań, Minimalne wymagania i wyjaśnienie MSWiA).

Przyglądając się powyższej delegacji ustawowej widać, że informatyzacja wiąże się w prosty sposób z problematyką normalizacji, a właśnie trwają prace nad zmianą ustawy o normalizacji (mówiąc w skrócie i wielkim, być może krzywdzącym, uproszczeniu: chodzi o "prywatyzacje PKN" wraz z zapewnieniem, że do Polskiego Komitetu Normalizacji nie będzie miała zastosowania ustawa o dostępie do informacji publicznej, wraz z jasnym zapewnieniem ochrony prawnoautorskiej dla Polskich Norm oraz publicznym finansowaniem działalności w znacznym stopniu; por. również O stosowaniu Polskich Norm i minimalnych standardach w informatyzacji oraz dyskusję pod tekstem Plan Informatyzacji Państwa na lata 2007-2010 - projekt)

Wspomniane rozporządzenie nie jest jedynym, które związane jest z omawianym zagadnieniem. Mamy np. rozporządzenia wydane na podstawie ustawy o narodowym zasobie archiwalnym i archiwach (por. Niezbędne elementy struktury dokumentów, Dokumenty elektroniczne w archiwach), są też akty wykonawcze do ustawy o podpisie elektronicznym (por. ostatnio: Formularze i wzory: zręby nowego quasi prawa - projekt rozporządzenia), rozporządzenia do KPA (por. Struktura i sposób sporządzania pism w formie dokumentów elektronicznych) jest rozporządzenie w sprawie Biuletynu Informacji Publicznej. Już na poziomie ustaw i rozporządzeń polski system prawa nie posługuje się spójnym słownikiem pojęć, w różny sposób podchodzi do otwartości standardów, a nawet są wątpliwości dotyczące praw wyłącznych do standaryzacyjnych dokumentów..

Tymczasem wciąż nie ma jasnych zasad dokonywania zamówień publicznych (a może zasady są, jednak nie ma jak egzekwować tych zasad: Podobają mi się brunetki, ale również dziewczyny mające cechy równoważne, chociaż są też pierwsze jaskółki: Specyfikacja Płatnika to informacja publiczna - orzekł sąd). W obowiązującym stanie prawa nie ma żadnych skutcznych sposobów dochodzenia roszczeń w przypadku niezachowania przez administrację publiczną zasad dostępności (w tym np. WAI, czyli Web Accessibility Initiative).

Nie to, że nie wierzę w możliwość skutecznego realizowania uchwał Rady Ministrów, warto jednak mieć w pamięci oceny Najwyższej Izby Kontroli na temat wcześniejszych dokumentów strategicznych, a zwłaszcza zarzuty, które padły w opublikowanym niedawno wszak raporcie: NIK zaobserwowała, że urzędnicy uznają dokument Strategia ePolska (ze stycznia 2004) za dokument "w zasadzie o charakterze deklaratywnym", nie zaś narzucającym konkretne zadania i terminy (por. NIK, Sejm, Rząd o informatyzacji...).

Stąd właśnie początkowo postawione pytania o formę i "umocowanie" Krajowych Ram Interoperacyjności, o to, w jaki sposób zagwarantować przestrzeganie obowiązków wdrażania interoperacyjności, by stanowiły one faktyczne zobligowanie administracji publicznej do zapewnienia współdziałania systemów, a nie były jedynie zbiorem „niezobowiązujących sugestii i wskazówek”. Zawsze w takich przypadkach przydatne są przepisy ustawowe - wytyczne powszechnie obowiązującego prawa, które w przypadku braku określonego działania ze strony zobowiązanych dają mechanizmy kontroli sądowej i wskazują wzorce odpowiedzialności.

Dlatego trzeba odnotować doniesienia z Danii, gdzie ogłoszono właśnie plany wdrożenia wydanej niedawno rezolucji parlamentarnej, zgodnie z którą otwarte standardy w administracji publicznej mają przestać być jedynie sugestią, a stosowanie (wskazanych) standardów ma stać się obligatoryjne (obowiązkowe - por. Mandatory Open Standards in Denmark oraz Openize Denmark, Parliament Orders). Duński plan implementacyjny przewiduje, że od 1 stycznia 2008 roku wskazane w tamtejszych ramach interoperacyjności standardy mają być obowiązkowo stosowane, chyba, że zajdą szczególne okoliczności uzasadniające brak stosowania, ale w takim przypadku organy administracji publicznej mają raportować brak możliwości wraz ze wskazaniem powodu stosowania w danym przypadku rozwiązań zamkniętych. Takie notyfikacje kierowane do specjalnej agendy (National IT and Telecom Agency) byłyby następnie publikowane. Być może to właśnie jest jedno z możliwych rozwiązań dla polskich „ram”?

W dyskusji (również polskiej) padają też postulaty wprowadzenia mechanizmu obligatoryjnego audytowania postępów wprowadzania interoperacyjności. Mowa jest o kwartalnej, półrocznej lub rocznej perspektywie. Raporty na temat postępów wdrażania interoperacyjności powinny być publikowane (być może w BIP?). Jeśli robić audyty tego typu, to może warto wypracować metody pomiaru efektywności (w tym pomiaru statystycznego, dyseminacja) wdrażania interoperacyjności w administracji publicznej? Można publikować poradniki (kodeksy) dobrych praktyk (best practice guide). Określenie jasnych zasad pozwoli również organizacjom pozarządowym uruchamianie społecznej kontroli postępów procesu wprowadzania współdziałania systemów (być może powstaną jakieś "watchdogi" publikujące niezależne ekspertyzy, opracowania i raporty).

W końcu dyskusja o tym, jaka jest różnica między "postulatem" a "rekomendacją" w zakresie interoperacyjności jest mało interesująca. Chodzi przecież o to, by te systemy ze sobą współpracowały, chodzi o to, by państwo (organizacja państwowa niezależnie od tego czy mówimy o administracji szczebla centralnego czy samorządowego) nie wstępowało na ścieżkę uzależnienia od jednej technologii, dostarczanej przez jednego z dostawców. Chodzi o to, by obywatel nie był "wykluczony", by nie był - mówiąc wprost - dyskryminowany. Trzeba zatem wskazać precyzyjnie standardy do wdrożenia, stworzyć mechanizmy kontroli wdrażania, określić realną odpowiedzialność za brak działań związanych z realizacją przyjmowanej polityki.

O dyskusji nad standaryzacją i interoperacyjnością w informatyzacji czytaj również: Migawki z Legionowa - dyskusja o interoperacyjności, standardach i informatyzacji państwa. A sam tytuł niniejszej notatki jest prowokacyjny, bo ramy pewnie by nam się przydały. Pytanie tylko, co w nich przeczytamy.

Opcje przeglądania komentarzy

Wybierz sposób przeglądania komentarzy oraz kliknij "Zachowaj ustawienia", by aktywować zmiany.

Standaryzacja eDokumentu....

Dokument aby był dokumentem musi zawierać określone elementy. Przykładem niech będzie postać faktury VAT. Jest jasno określone co ma zawierać. Mniej wagi przyłożono do wizualnej postaci dokumentu. Skupiono się na jego zawartości.
To już jest pierwszy etap standaryzacji.

Drugim etapem jest jego zapis w formie elektroniczej.
A tutaj trzeba określić:

  1. Kodowanie znaków. UTF-8 obejmuje wszystkie
  2. Typ kroju czcionki. Jedna dla wszystkich
  3. Rozmiar czcionki w:
    1. Treści dokumentu
    2. Tytule dokumentu
    3. Nagłówkach rozdziałów, podrodziałów, i.t.d.
  4. Marginesy (górny, dolny, lewy, prawy)
  5. Dopuszczalną zawartość nagłówka i stopki eDokumentu
  6. Szerokość tabulatora (wcięcie)
  7. Szerokość wcięcia akapitu
  8. Dopuszczalną szerokość pól na obszary graficzne
  9. Sposób dzielenia tabel pomiędzy stronami
  10. Sposób formatowania akapitów i wyliczeń... Pominięcie spacji czy tabulatora jako znaku formatującego wizualnie stronę

Wymieniłem pewnie tylko kilka niezbędnych... Ale jak widać trochę tego jest do ustandaryzowania. Bez takich ustaleń dowolny eDokument będzie wyglądał zupełnie inaczej na wielu edytorach tekstowych.
Jak widać, idealnym rozwiązaniem jest zastosowanie zasad podobnych jak do budowy strony wizualizowanej przez przeglądarki www. Zapewni to jednolitość wyglądu eDokumentu bez względu system operacyjny. Choć też trzeba wiele ustalić jednoznacznie i nieodwołalnie. Ale to można załatwić np. CSS lub innymi mechanizmami definicyjnymi.

Ale gdyby zrezygnować ze sztywnego opisywania wizualnej formy eDokumentu, a skupić się jedynie na tym, że ma mieć niezmienialną treść, to zapewnienie kodowania w UTF-8 i przesył w formie dokumentu XML zagwarantuje przepływ informacji. Estetykę wizualną na ekraniku czy papierku można pozostawić użytkownikowi końcowemu. W końcu przecież ważna jest treść i jej autoryzacja ePodpisem, a nie układ wizualny. Ważne by w dokumencie drukowanym była sygnatura ePodpisu którym eDokument został podpisany.

Idąc dalej w upraszczaniu zagadnienia, można założyć, że nie wygląd ma znaczenie, a jedynie treść czyli ciąg znaków stanowiących zawartość eDokumentu. Zagwarantowanie nienaruszalności tego ciągu co do zawartości daje pewność, że eDokument jest oryginalny z tym jaki został podpisany ePodpisem. A wygląd.... No cóż... Różne są gusta... Zatem każdy może chcieć sobie to poustawiać jak jemu wygodniej. Najważniejsze jest aby nie mógł zmienić treści dokumentu, czyli ilości i kolejności znaków tekstu.
A skoro tak, to wystarczy UTF-8 i tekst eDokumentu jako niesformatowany txt, znacznik końca linii określi jednoznacznie jak wyglądają linijki tekstu. Z treści eDokumentu będzie wynikać jasno co jest nagłówkiem, a co treścią eDokumentu... I jest standaryzacja przesyłu eDokumentu. Standaryzja idąca tak daleko, że nawet maszyny DOS-owe to mogą wyświetlić... A nie jedynie słuszna już pożądana w eUrzędach MS Vista.

Pozdrawiam.

Strategia otwartości rządu Republiki Południowej Afryki

VaGla's picture

Wiadomość z 22 lutego 2007: rząd Republiki Południowej Afryki wydał oświadczenie, zgodnie z którym przyjęto tam właśnie strategię przechodzenia agend rządowych na wolne oprogramowanie bazujące na otwartych standardach. Zgodnie z przyjętą strategią (): nowe oprogramowanie przygotowane dla administracji (oraz wewnątrz administracji) ma bazować na otwartych standardach, a używane w tej chwili oprogramowanie ma migrować do FOSS (free and open source software). Więcej w tekście SA government to switch to open source oraz na rządowej stronie Open Source Software in Government.

Dokumenty rządowe Republiki Południowej Afryki dostępne są online:

Piotr VaGla Waglowski

VaGla
Piotr VaGla Waglowski - prawnik, publicysta i webmaster, autor serwisu VaGla.pl Prawo i Internet. Członek Rady ds Cyfryzacji przy Ministrze Cyfryzacji, ekspert w Departamencie Oceny Ryzyka Regulacyjnego Ministerstwa Rozwoju, felietonista miesięcznika "IT w Administracji" (wcześniej również felietonista miesięcznika "Gazeta Bankowa" i tygodnika "Wprost"). Uczestniczył w pracach Obywatelskiego Forum Legislacji, działającego przy Fundacji im. Stefana Batorego w ramach programu Odpowiedzialne Państwo. W 1995 założył pierwszą w internecie listę dyskusyjną na temat prawa w języku polskim, Członek Założyciel Internet Society Poland, pełnił funkcję Członka Zarządu ISOC Polska i Członka Rady Polskiej Izby Informatyki i Telekomunikacji. Był również Członkiem Rady Informatyzacji przy MSWiA, członkiem Zespołu ds. otwartych danych i zasobów przy Komitecie Rady Ministrów do spraw Cyfryzacji oraz Doradcą społecznym Prezesa Urzędu Komunikacji Elektronicznej ds. funkcjonowania rynku mediów w szczególności w zakresie neutralności sieci. W latach 2009-2014 Zastępca Przewodniczącego Rady Fundacji Nowoczesna Polska, w tym czasie był również Członkiem Rady Programowej Fundacji Panoptykon. Więcej >>