Pre mna je toto znenie trocha matuce, ak to takto berieme, tak mame zadavaciu (GUI pre vyplnovanie udaje), schvalovaciu (podpisovanie), a “normalizacnu” (data). zadavacia, schvalovacia cast nema byt preco sucastou formulara. iba data.
1 Like
Tak asi takto zatiaľ:
K bodu 15 (K zmenám riešenia modulu úradnej komunikácie)
Z navrhovaného znenia vyplýva, že súčasný modul úradnej komunikácie, ktorý plní úlohy súvisiace so zdieľaním údajov medzi orgánmi verejnej moci pri výkone verejnej moci, by mal byť nahradený novým riešením, ktoré má byť podľa NKIVS implementované ako iPaaS. V rámci doložky vplyvov na informatizáciu však predkladateľ deklaruje, že ide o zmeny súčasného modulu úradnej komunikácie, čo je v rozpore s tvrdením o novom riešení, ktorým má byť zabezpečované zdieľanie údajov.
Žiadame predkladateľa, aby vysvetlil tieto rozpory, a aby objasnil, aký dopad bude mať navrhované riešenie na už zrealizované integrácie na modul úradnej komunikácie.
Zároveň žiadame predkladateľa, aby v doložke vplyvov na rozpočet VS vyčíslil finančné náklady na realizáciu navrhovaného riešenia, a finančné náklady na zmeny SW riešení ostatných správcov ISVS, ktorí sú integrovaní na súčasné riešenie modulu úradnej komunikácie.
K bodu 17. (K inštitucionalizovaní vládneho cloudu)
V prvom rade si dovoľujeme predkladateľa upozorniť, že na európskej úrovni prebieha tvorba štandardov pre cloud computing a prevádzkovanie cloudových služieb a preto je žiadúce, aby špecifické pravidlá na národnej úrovni boli schválené až po prijatí rámca na európskej úrovni.
Návrh neobsahuje úpravu špecifických otázok, ktoré prekračujú spoločný európsky rámec, čiže najmä otázky v súvislosti so spracovaním a ochranou osobných údajov, s uchovávaním a vlastníctvom údajov vytvorených vo vládnom cloude, s určením priamej a nepriamej zodpovednosti za nedostupnosť služieb, zmenami v poskytovaných službách, prípadne kompenzáciami za takéto zlyhania alebo zmeny.
Domnievame sa, že návrh by mal stanoviť aj rozsah povinných náležitostí zmluvy o poskytovaní cloudových služieb, ako napr. prístup k údajom a ich zdieľanie tretím stranám, poskytovanie súčinnosti alebo doložky o mlčanlivosti.
Žiadame preto predkladateľa, aby dopracoval návrh o špecifické otázky, najmä v súvislosti so spracovaním a ochranou osobných údajov, s uchovávaním a vlastníctvom údajov vytvorených vo vládnom cloude a s určením priamej a nepriamej zodpovednosti za nedostupnosť služieb.
K bodom 33. až 35.(K zmene spôsobu zverejňovania elektronických formulárov)
Žiadame predkladateľa, aby upravil navrhované znenia novelizačných bodov 33. až 35., a to tak, aby bola zadávacia časť oddelená od schvaľovacej časti (dátový model a transformácie pre schválenie/vyjadrenie vôle/tlač, atď.), a to z dôvodu, že kým zadávacia časť je zodpovednosťou tvorcu služby, tak schvaľovacia časť je zodpovednosťou správcu prístupového miesta (toto je relevantná časť elektronického formulára, ktorá by v ňom mala ostať).
Účelom navrhovaného znenia je podľa predkladateľa, dosiahnutie „jednotného používateľského zážitku pri zadávaní údajov“. Domnievame sa, že účel, ktorý predkladateľ sleduje, je možné omnoho efektívnejšie a lacnejšie (a paradoxne aj omnoho úspešnejšie) dosiahnuť vhodnými metodickými usmerneniami (dizajn/ux manuály), prípadne knižnicou štandardných komponent web používateľského rozhrania (podobne ako napr. vo Veľkej Británii). Prístupové miesta by sa v takom prípade mali do budúcna sústrediť na to, aby sa vedeli na takéto zadávacie časti prepájať (predpokladá sa, že fungujú v online režime). Pre inštitúcie, ktoré nemajú vlastné systémy na poskytovanie služieb je samozrejme vhodné, aby existovala cesta ako zadávaciu časť vytvoriť automatizovane (nie programovaním), s využitím samotnej definície (modelu) formulára.
Vzhľadom na to, že ide o popis cieľového stavu, odporúčame predkladateľovi, v súčinnosti s ostatnými zainteresovanými stranami, zohľadniť čas pre jeho dosiahnutie stanovením prechodného obdobia.
Žiadame predkladateľa, aby v doložke vplyvov na rozpočet VS vyčíslil finančné náklady navrhovanej zmeny a v doložke vplyvov na informatizáciu vysvetlil aký bude dopad na SW riešenia ostatných správcov ISVS. Sme toho názoru, že návrh núti všetky formuláre implementovať nanovo, pričom výsledný efekt nebude mať pre používateľov služieb žiadnu pridanú hodnotu.
K bodu 41. (K zavedeniu centrálneho registra elektronických rozhodnutí)
Myšlienka koncentrovať elektronické úradné dokumenty „na jedno miesto“ nie je a priori zlá, ale už v čase predloženia návrhu je potrebné poznať a definovať aspoň v hrubých obrysoch minimálne dve alternatívy návrhu funkčného riešenia, opísať ich v analytickom dokumente a pre každé z nich pripravovať návrh zákona.
Zastávame názor, že zákon má vymedzovať najmä povinné osoby a ich povinnosti (biznis aktérov a vzťahy), prípadne náležitosti rozhodnutia (metaúdaje), referenčná architektúra riešenia by mala byť obsahom analytického dokumentu. Bez toho, aby bol súčasne s návrhom zákona známy aj návrh architektúry riešenia IS, hrozí, že takto navrhnutá úprava založí do budúcnosti nároky, ktoré sa dajú vykladať rôzne a ich následkom vznikajú robustné a komplikované riešenia IS.
Keďže návrh počíta s ukladaním dokumentov, je tak zároveň aj popretím jedného zo základných nástrojov eGovernmentu implementovaného OPISom - zdieľania údajov (nie dokumentov). Účelom bolo v referenčných registroch zachytiť materiálnu podstatu rozhodnutia (výsledok rozhodovania) a nie formálnu podstatu, čiže rozhodnutie ako dokument.
Zároveň sa domnievame sa, že Centrálny register elektronických rozhodnutí (CRER) nie je registrom v zmysle ust. § 49 písm. a) zákona o eGovernmente, nakoľko nie je miestom uchovávania objektov evidencie, ktoré vytvára.
Žiadame predkladateľa, aby buď predložil reformný zámer, štúdiu uskutočniteľnosti, prípadne iný analytický dokument, v ktorom predstaví minimálne dve alternatívy funkčného riešenia a jeho kreovania s využitím existujúcich centrálnych komponentov eGovernmentu - spoločných modulov ÚPVS (modul doručovania, modul dlhodobého uchovávania registratúrnych záznamov), alebo aby navrhované znenie tohto bodu bez náhrady vypustil. Napriek uvedeným výhradám k niektorým častiam návrhu, oceňujeme stanovenie rozsahu povinných náležitostí elektronického úradného dokumentu (odsek 3), ktoré navrhujeme v prípade vypustenia inštitútu CRER ponechať v zákone.
K doložke vplyvov na rozpočet VS
Doložka vplyvov neobsahuje vyznačenie negatívneho vplyvu na rozpočet verejnej správy a to aj napriek tomu, že návrh jednoznačne obsahuje zmeny a doplnenia, ktoré budú mať dopad na SW riešenia ostatných inštitúcií VS, ktoré využívajú centrálne komponenty eGovernmentu.
V tejto súvislosti žiadame predkladateľa, aby predložil analýzu vplyvov na rozpočet verejnej správy, ktorá bude zohľadňovať nielen výdavky v rámci jeho kapitoly, ale aj výdavky jednotlivých správcov ISVS, ktorí sú integrovaný na centrálne komponenty eGovernmentu, ktoré vyplývajú z tohto návrhu.
K doložke vplyvov na informatizáciu
Doložka vplyvov na informatizáciu neobsahuje korektné údaje, nakoľko podľa nej sa navrhuje zmena IS CSRÚ, a to aj napriek tomu, že tento ISVS má byť nahradený úplne novým riešením (modulom dátovej a procesnej integrácie), ktoré má byť implementované ako iPaaS.
Žiadame predkladateľa, aby predložil doložku vplyvov s korektne vyplnenými údajmi, ktoré budú v súlade s informáciami z dôvodovej správy a zároveň s údajmi v Centrálnom metainformačnom systéme VS.
2 Likes
Návrh na zavedenie postupu elektronickej kontraktácie
Vzhľadom na chýbajúcu právnu úpravu elektronickej kontraktácie v oblasti verejného práva, dávame predkladateľovi na zváženie, či by nebolo vhodné tento inštitút upraviť v zákone o eGovernmente ako všeobecnú právnu úpravu, ktorou sa pri uzatváraní zmlúv v elektronickej podobe budú riadiť všetky orgány verejnej moci.
Vzhľadom na ústavný princíp „orgán môže konať len v rozsahu stanovenom zákonom“, je nevyhnutné, aby bol tento postup upravený zákonom, čim sa predíde nielen aplikačným problémom, ale zároveň sa zohľadnia nové možnosti, ktoré nástroje eGovernmentu ponúkajú už v súčasnosti.
Skúsim úvahu.: Ak nie je “schvaľovacia časť” súčasťou formulára, tak ako potom môžem zviazať/definovať “spôsob zobrazenia” ktoré sa má udiať pred vyjadrením vôle (schválením) používateľa? Ak je táto väzba voľná (resp. definuje ju niekto iný, lebo nie je súčasťou formulára) tak z môjho pohľadu úplne rozpájame (on je vždy len akou-takou ilúziou) WYSIWYS princíp.
2 Likes
Ak by ,schvalovacia cast" (zobrazenie pre podpis) nebola sucastou formulara, pripadne existovalo viac zobrazeni (samozrejme plati, ze podpisovatel a overovatel musia pouzit rovnake), tak:
- je otazne, kto a ako by ju schvaloval, takto je to schvalene v ramci formulara
- bolo by potrebne parovat formular na ,schvalovaciu cast", takto je to sucast formulara popisana v metdatach
- prinos nebude ziadny, vznikne len zmatok + zbytocne chyby a zneisti pouzivatelov
T.j. je to dobre tak, ako to je.
1 Like
Za mňa tu sú pripomienky k časti I. §24 a ďalej. Časť od začiatku potiaľto mám ešte rozpísanú. Na časti II-V. sa asi ani veľmi nedostanem.
Pripomienka k §24 ods. 2:
Žiadame tento novelizačný bod vypustiť. Súčasne žiadame z §24 ods.2 vypustiť písm. c) a d) a v §24 ods. 3 doplniť nový odsek f), ktorý znie: „získavať automatizovaným spôsobom referenčné údaje, ak sú na prípravu podania potrebné“.
Dôvodovú správu k bodu 36 žiadame doplniť o nasledovnú vetu: „Elektronické služby majú byť realizované flexibilným online spôsobom. Použitie elektronického formulára nie je nevyhnutne potrebné až do ukončenia interakcie s používateľom.“
Odôvodnenie:
Historicky, najmä z dôvodu nízkej dostupnosti online pripojenia do siete internet a slabej schopnosti vytárania online elektronických služieb zo strany OVM, bol „elektronický formulár“ navrhnutý tak, aby súčasne plnil viacero funkcií: umožnenie vypĺňania, automatizovaného vkladania údajov, validáciu zadaných údajov, prezentáciu formulára, vrátane možnosti jeho vytlačenia do presne určenej listinnej formy a aj vykonanie samotného podania. Týmto spôsobom sa však neúmerne zvýšila zložitosť (a tým aj náklady) na vytváranie nových elektronických formulárov. Výsledkom je, že povinnosť vytvárania elektronických formulárov pre všetky podania a úradné dokumenty je dodržiavaná iba sporadicky, používané technológie pre elektronické formuláre sú zložité a neflexibilné (napr. požiadavka na vytváranie vizualizačnej transformácie na tlač pomocou XSLT).
Zároveň však v súčasnosti je prakticky pre každý subjekt dostupné online pripojenie do siete internet a vytváranie online elektronických služieb sa výrazne rozšírilo a zjednodušilo. V súčasnosti existuje odborný konsenzus, ktorý je aj v súlade so závermi pracovnej skupiny ÚPPVII Lepšie služby vyjadrených v schválených dokumentoch strategických priorít NKISV Multikanálový prístup a Integrácia a orchestrácia, podľa ktorého je potrebné striktne oddeľovať pri poskytovaní elektronických služieb dve etapy:
- Príprava podania, resp. vedenie životnou situáciou – tento krok má byť zabezpečovaný online prostriedkami v správe gestora príslušného podania/ŽS, dôraz je kladený na používateľský komfort; elektronický formulár nie je v tejto etape využívaný.
- Samotné vykonanie podania – uskutoční sa po získaní všetkých údajov potrebných na vykonanie podania; údaje sú vložené do elektronického formulára, ktorý používateľ ďalej nemodifikuje, iba je mu zobrazený; následne je tento vyplnený elektronický formulár – t.j. elektronické podanie – autorizovaný a odoslaný.
Týmto rozdelením je možné zmenšiť nároky kladené na elektronický formulár, čo povedie k zníženiu nákladov na jeho vytváranie a to aj zvýšením počtu riešení na trhu schopných požiadavky zákona v tejto oblasti realizovať. Zároveň týmto spôsobom OVM vytvárajúce elektronické služby získajú väčšiu flexibilitu a kontrolu nad postupmi v rámci etapy 1), čo povedie k zvýšeniu používateľského komfortu.
Z pohľadu zákona je preto vhodné taktiež tieto dve etapy oddeliť. V rámci §24 ods.2 je vhodné ponechať funkčnosť nevyhnutnú na používanie elektronického formulára a funkčnosť, ktorá má byť povinne vykonávaná v etape 1) je vhodné uviesť na miestach zákona, ktoré sa týkajú elektronických služieb, napr. §24 ods.3.
Pripomienka k §24 ods.3:
Žiadame tento novelizačný bod vypustiť.
Súčasne žiadame z §24 ods.3 písm. d) zmeniť nasledovne: „uložiť elektronické podanie na pamäťovom médiu alebo do rozpracovaných správ elektronickej schránky“.
Súčasne je možné zvážiť doplnenie ustanovení o elektronickej podateľni o povinnosť, že podateľňa pri spracovaní prijatého podania uloží toto podanie do odoslaných správ elektronickej schránky každého subjektu, ktorý podateľňa identifikuje že podanie autorizoval, ak sa v odoslaných správach elektronickej schránky toto podanie ešte nenachádza.
Odôvodnenie:
Existuje množstvo podaní, pri ktorých nie je predpoklad využívania funkcií „uloženia neúplného podania“ a „prevzatia rozpracovaného podania“ zo strany používateľov – napr. pre jednoduché podania. Naopak, povinná implementácia týchto požiadaviek bude vyžadovať nemalé náklady, ktoré takto budú neúmerné výslednému efektu. Zároveň pre komplexné podania či životné situácie spravidla rozpracovaný stav nie je možné reprezentovať iba „polovyplneným“ elektronickým formulárom, ale možnosť prerušenia práce zaisťuje špecializovaný portál vlastnými komplexnými prostriedkami.
Zároveň príprava podania nie je priamo spojená s elektronickou schránkou – napr. pre väčšinu podaní je zmysluplné umožniť ich prípravu aj bez autentifikácie používateľa, niektoré podanie je možné podať aj anonymne, častokrát podanie pripravuje viacero subjektov spoločne. Vytvorenie novej sady povinností „voči elektronickej schránke“ spôsobí v týchto situáciách iba väčšiu právnu neistotu, pri ktorej riešení je riziko – ako poznáme z minulosti – že dôjde k obmedzeniu funkčnosti služieb na úkor používateľského komfortu.
Samozrejme považujeme za vhodné, aby správca modulu elektronických schránok umožnil uloženie podania, aj rozpracovaného, prevzatie a aktualizovanie podania – čo podľa dostupných informácií už sú realizované funkcie príslušného modulu ústredného portálu.
Zároveň považujeme funkciu prehľadu odoslaných podaní subjektu za užitočnú. Potrebné je zvážiť vhodnosť a efektívnosť ukladania všetkých odoslaných podaní „na jednom mieste“ – v elektronickej schránke. Tento prístup zvýši najmä kapacitné nároky na prevádzkovanie elektronických schránok a nemá priamu obdobu v doterajšom listinnom spracovaní podaní. Zároveň týmto spôsobom dochádza k nadštandardnej kumulácii osobných údajov v module elektronických schránok, ktoré používateľ v niektorých prípadoch nebude vedieť riadiť, napr. ak elektronickú schránku nepoužíva. Ak výsledkom analýzy bude, že povinné ukladanie odoslaných správ do elektronickej schránky je vhodné, navrhujeme ho realizovať centrálne po prijatí podania elektronickou podateľňou a identifikáciou subjektov, ktoré podanie autorizovali.
V prípade ponechania tohto novelizačného bodu žiadame v rámci sprievodných častí materiálu vyčísliť skutočné odhadované náklady na realizáciu týchto funkcií všetkými OVM.
Pripomienka k §25 ods.4:
Možnosť autorizovať podanie a jeho prílohy spoločne považujeme za správnu. Vzhľadom na efektívnosť spracovania podaní považujeme z dlhodobého hľadiska za správne podporovať iba jeden spôsob spojenia príloh s podaním, a vhodnejší je práve prístup spoločne autorizovaného podania s prílohami. Preto navrhujeme možnosť pripojenia príloh k elektronickému podaniu vložením el. podania spolu s prílohami do elektronickej správy zrušiť, samozrejme s ponechaním dostatočného prechodného obdobia na prechod k cieľovému stavu.
Zároveň žiadame do dôvodovej správy k tomuto bodu doplniť za existujúci text nasledovnú vetu: „Tento spôsob autorizácie bude prístupovými miestami prioritne podporovaný.“
Pripomienka k §26 ods.8:
Žiadame znenie odseku 8 zmeniť nasledovne: „Modul elektronických formulárov je v časti obsahujúcej elektronické formuláre pre elektronické úradné dokumenty verejný a správca modulu elektronických formulárov ho sprístupňuje každému bezodplatne prostredníctvom ústredného portálu.“
Odôvodnenie:
Elektronický formulár, pokiaľ nie je vyplnený, je iba šablónou, ktorá neobsahuje žiadne osobné ani iné citlivé údaje. Zároveň po vyplnení sa elektronický formulár zasiela adresátovi, ktorý jeho šablónu môže ľubovoľne použiť ďalej – aj zverejniť. Preto nevidíme žiadny dôvod na plošné vylúčenie prístupnosti elektronických formulárov. Vzhľadom na to, že iná časť modulu elektronických formulárov má byť verejne prístupná (viď. §24 ods.9), predpokladáme že jednotný prístup pre obe časti tohto modulu – ich verejná dostupnosť – bude aj z funkčného a prevádzkového hľadiska efektívnejší.
Zároveň verejná dostupnosť „šablón“ elektronických úradných dokumentov zjednodušuje pre fyzické a právnické osoby ich spracovanie, keďže si môžu vopred upraviť postup a nástroje ich spracovania podľa ich skutočnej štruktúry, a to ešte pred samotným doručením elektronického úradného dokumentu. Tento prístup sa uplatní najmä pri strojovom spracovaní elektronických úradných dokumentov, ktorého deklarované zefektívnenie je jedným z hlavných účelov plošného zavedenia elektronických formulárov. Analogicky, ak by elektronické formuláre pre podania neboli vopred prístupné pre OVM, mali by iba obmedzené možnosti ich automatizovaného spracovania.
Pripomienka k §28 ods.7:
Navrhujeme vypustiť tento novelizačný bod.
Odôvodnenie:
Dodržiavanie štandardov ISVS je už uložené ako povinnosť pre všetkých správcov ISVS všeobecne záväzným predpisom – viď. §3 ods.4 písm.i) zákona č.275/2006 Z.z. Nevidíme zmysel v duplikovaní tejto povinnosti. Naopak, tento prístup iba podporí „výkladové spory“, či dodržiavanie štandrdov ISVS je nevyhnutné pre všetky ostatné oblasti, ktoré nie sú v zákone explicitne vymenované.
Pripomienka k §28a:
Žiadame §28a nahradiť nasledovným znením:
㤠28a
Zdieľanie elektronických rozhodnutí
(1) Orgán verejnej moci je povinný sprístupniť elektronické úradné dokumenty, ktoré vydal ako rozhodnutia (ďalej len „elektronické rozhodnutie“) prostredníctvom modulu procesnej integrácie a integrácie údajov. Táto povinnosť sa nevzťahuje na elektronické rozhodnutia vo veciach, v ktorých orgán verejnej moci rozhoduje zápisom do informačného systému alebo evidencie ustanovenej zákonom a nevydáva osobitné rozhodnutie.
(2) Orgán verejnej moci je pri sprístupnení elektronického rozhodnutia podľa odseku 1 súčasne povinný sprístupniť údaje
a) označenie konania pred orgánom verejnej moci,
b) označenie súvisiacich konaní o opravných prostriedkoch, mimoriadnych opravných prostriedkoch a ústavných sťažnostiach, vrátane označenia orgánu verejnej moci, ktorý o nich koná,
c) údaje o účastníkoch konania v rozsahu, v akom sú v ňom uvedené,
d) označenie orgánu verejnej moci, ktorý ho vydal,
e) označenie predmetu konania,
f) dátum vydania,
g) dátum zmeny alebo zrušenia,
h) údaj o právoplatnosti a dátum nadobudnutia právoplatnosti,
i) údaj o vykonateľnosti a dátum nadobudnutia vykonateľnosti,
j) jednoznačný = identifikátor.
„
Súčasne znenie §17 ods.5 písm. b) nahradiť nasledovným: „na tento účel nie je možné použiť elektronické rozhodnutie prístupné podľa §28a ods. 1“
Odôvodnenie:
Sprístupnenie elektronických rozhodnutí na G2G zdieľanie je správny cieľ, ktorý môže napomôcť realizácii princípu „1 krát a dosť“ a vítame ho.
Pri realizácii tohto cieľa najťažším bude dosiahnuť „vytiahnutie“ elektronických rozhodnutí z prostredia OVM, ktoré ich vydávajú do centrálneho komponentu, ktorý umožňuje ich zdieľanie a zároveň vytváranie určitých metadát spolu s elektronických rozhodnutím, čo uľahčí jeho ďalšie automatizované spracúvanie.
Na druhej strane, nie je jasné aký účel pri dosahovaní tohto cieľa má mať zriadenie nového centrálneho registra. Podľa našich skúseností je zdieľanie elektronických rozhodnutí analogické ku zdieľaniu akéhokoľvek iného typu údajov. V posledných rokoch sa „master data management“ realizovaný kopírovaním všetkých údajov do centrálneho komponentu ukázal ako nerealizovateľný. Riešením je ponechanie správy údajov v kompetencii OVM ktoré ich vytvárajú a prostredníctvom centrálnych komponentov (modulom dátovej integrácie) zabezpečiť iba sprostredkovanie týchto údajov ich konzumentom. Nevidíme dôvod, aby tento istý mechanizmus nebol použitý aj pre zdieľanie elektronických rozhodnutí.
V súlade s postupom uvedeným v dokumente Strategickej priority NKIVS Manažment údajov má návrhu prípadného centrálneho komponentu predchádzať analýza a porovnanie jednotlivých možností a uvažované riešenie má zohľadniť širší kontext zdieľania a referencovania elektronických spisov a ich jednotlivých položiek.
Pre jednoduchú evidenciu a automatizované spracovanie údajov podľa ods.2 navrhujeme ich reprezentáciu samostatnými položkami elektronického formulára, prostredníctvom ktorého je elektronické rozhodnutie realizované.
Alternatívne je umožnenie/povinnosť zdieľania elektronických rozhodnutí možné na administratívnej úrovni realizovať vyhlásením elektronických rozhodnutí za referenčné údaje. V takomto prípade nie je potrebné vkladať §28a. Postupným určovaním registrov, v ktorých tieto údaje sú uložené, je možné nahradiť aj prechodné obdobie, ktoré je pre umožnenie zdieľania elektronických rozhodnutí zavedené v §60f ods.4.
Pripomienka k §31 ods.2:
Navrhujeme písm. b) vypustiť, t.j. §31 ods.2 bude znieť: „Ustanovenia o elektronickom doručovaní sa nepoužijú a doručovanie sa spravuje ustanoveniami o doručovaní podľa osobitných predpisov, ak osobitný predpis ustanovuje, že sa doručuje výlučne v listinnej podobe.“
Súčasne navrhujeme vložiť do §31a nový ods. 8 s nasledovným znením: „Správca modulu elektronického doručovania zabezpečí doručenie elektronického dokumentu v listinnej forme podľa ods.1 aj vtedy, ak sa doručuje osobám vo výkone trestu odňatia slobody, vo väzbe, osobám umiestneným v zariadeniach pre výkon ústavnej starostlivosti a ochrannej výchovy alebo tomu, kto požíva diplomatické výsady a imunity.“
Odôvodnenie:
Ide o analogickú zmenu, ako bola vykonaná pre postup podľa pôvodného §31 ods.2 písm.a) (prípad neaktivovanej elektronickej schránky).
Zároveň OVM, ktorý je odosielateľom, nemá v súčasnosti žiadne možnosti posúdiť, či adresát elektronického dokumentu je vo výkone trestu odňatia slobody, vo väzbe atď. Postačí, ak toto posúdenie vykoná správca MED.
Pripomienka k §31a ods.1:
Navrhujeme preformulovať znenie tohto odseku tak, aby orgán verejnej moci vždy odoslal elektronický dokument prostredníctvom MED a až následne správca MED začal skúmať či je elektronická schránka aktivovaná, a v závislosti od toho zvolil spôsob doručovania.
Takýto postup je predpokladaný aj v dôvodovej správe.
Pripomienka k §31a ods.4:
Znenie znenie ods.4 nahradiť nasledovným: „Správca modulu elektronického doručovania môže zabezpečiť vyhotovenie rovnopisu prostredníctvom poštového podniku, ktorý vykoná jeho doručenie adresátovi.“
Odôvodnenie:
Nie je jasné, prečo v návrhu má vyhotovenie rovnopisu zabezpečovať prevádzkovateľ IOM, ktorým v zmysle §7 ods.2 sú napr. mestská časť v Bratislave a Košiciach. Naopak, poštové podniky pri doručovaní hybridnej pošty bežne umožňujú do podniku doručiť dokument v elektronickej forme a jeho vytlačenie do listinnej formy zabezpečia vlastnými kapacitami.
Pripomienka k §36 ods.8:
Žiadame vypustiť tento novelizačný bod.
Odôvodnenie:
Požiadavka na overovanie autorizácie elektronického dokumentu prostredníctvom kvalifikovanej služby vytvára zjavnú nerovnováhu voči overovaniu autorizácie listinného dokumentu, ktorá sa vykonáva iba vizuálne. Táto nerovnováha nie je nijakým spôsobom odôvodnená. Ak teda podľa dôvodovej správy navrhované ustanovenie má za cieľ „redukovať možnosti pre jeho [dôveryhodnosti overovania] zneužívanie (napr. pri výrobe falošných dokumentov použiteľných na právne účely)“, tento cieľ nebude dosiahnutý pre listinné dokumenty – pri ktorých je výroba falošných dokumentov dokonca jednoduchšia ako pre elektronické. Chrániť iba „polovicu“ spôsobov konverzie nemá z bezpečnostného hľadiska význam, resp. ochrana musí byť vyvážená.
Zároveň táto novela v §39 ods.1 obmedzuje použiteľnosť produktu zaručenej konverzie iba na rozsah osvedčenej kópie, čo ďalej uvedené riziká znižuje.
Požiadavka na používanie kvalifikovanej služby vytvára pre vykonávateľov zaručenej konverzie nemalé technické a aj finančné náklady.
Z týchto dôvodov považujeme vyžadovanie použitia kvalifikovanej služby za neopodstatnenú.
Pripomienka k §39 ods.1:
Obmedzenie použiteľnosti produktu zaručenej konverzie na rozsah iba ako osvedčená kópia pôvodného dokumentu považujeme za správne.
Podľa nášho názoru je takéto obmedzenie potrebné vzhľadom na bezpečnostné riziká spojené s používaním produktu zaručenej konverzie, najmä nemožnosť následne overovať autenticitu dokumentu, z ktorého bola zaručená konverzia vykonaná.
Týmto spôsobom sa de-facto realizácia zaručenej konverzie stáva špeciálnym prípadom vytvorenia osvedčenej kópie dokumentu. Preto navrhujeme tieto inštitúty čo najviac zosúladiť a to tak z hľadiska potrebných úkonov a súvisiacich evidencií (ktoré implicitne vyjadrujú požiadavky na bezpečnostné záruky), ako aj v oblasti nákladov / poplatkov a okruhu osôb oprávnených zaručenú konverziu vykonávať.
V súlade s týmto pohľadom odporúčame prehodnotiť potrebu centrálnej evidencie záznamov o vykonanej zaručenej konverzii v zmysle §39 ods.5 (a ďalších) a to najmä s ohľadom na súvisiace náklady.
V súvislosti s obmedzením použiteľnosti produktu zaručenej konverzie odporúčame revidovať aj ustanovenie o ich použiteľnosti namiesto originálu v §25 ods. 3 a §27 ods.2.
Pripomienka k §39 ods. 8:
Za navrhované znenie žiadame doplniť vetu: „V týchto prípadoch orgán verejnej moci vykoná zaručený konverziu bezodplatne.“
Odôvodnenie:
Ak orgán verejnej moci vydá elektronický dokument vo formáte, ktorý nie je v súlade so štandardami ISVS, ide o porušenie požiadaviek všeobecne záväzného právneho predpisu – výnosu o štandardoch v zmysle §3 ods.4 písm.i) zákona č.275/2006 Z.z. Nepovažujeme za prípustné, aby náklady spojené s opravou tohto stavu na súladný so štandardami znášal iný subjekt, ako ten, ktorý porušenie pravidiel spôsobil.
Pripomienka k §56:
Rozšírenie správnych deliktov za porušovanie tohto zákona vítame a považujeme ho za správne.
Žiadame do zákona doplniť pre úrad podpredsedu vlády aj kompetenciu vykonávať kontrolu nad plnením ustanovení tohto zákona, analogicky ako je tento mechanizmus zavedený v zákone č.275/2006 Z.Z. v §4 ods.2 písm.d).
Odôvodnenie:
V súčasnosti sú mnohé ustanovenie zákona o e-Governmente opakovane porušované zo strany mnohých OVM (niektoré ustanovenia sú prakticky ignorované skoro všetkými OVM). Pri komunikácii s úradom podpredsedu vlády na túto tému jeden z argumentov, prečo úrad nevie efektívne túto situáciu riešiť bolo uvádzané, že nemá dostatočnú kompetenciu vyžadovať od iných OVM preukazovanie plnenia ustanovení tohto zákona. Ak sa novelu rozširuje okruh sankcií, potreba systematickej práce v tejto oblasti (kontrola nad plnením ustanovení tohto zákona) je o to väčšia.
Pripomienka k §60f ods.1:
Žiadame nahradiť nasledovným znením: „Orgány verejnej moci sú povinné splniť podmienku podľa § 6 ods. 6 prvej vety najneskôr do 1. novembra 2019.“
Odôvodnenie:
Nevidíme žiadny dôvod na špeciálne pravidlá pre ISVS vybudované s použitím prostriedkov z fondov EÚ, a to ani z hľadiska zabezpečenia udržateľnosti výsledkov projektov – táto požiadavka predsa nijakým spôsobom neznižuje ich použiteľnosť. Špeciálne zaobchádzanie pre takéto projekty, v prípade jeho ponechania v zákone, považujeme za potvrdenie domnienky, že ISVS vybudované z použitím prostriedkov z fondov EÚ sú menej kvalitné a menej flexibilné oproti „normálnym“ ISVS.
Zároveň nám nie je jasný zmysel konštrukcie navrhnutého prechodného obdobia kedy OVM „je povinný zabezpečiť najskôr od“ plnenie určitej povinnosti. Máme za to, že ohraničiť je potrebné najmä koniec prechodného obdobia, ktorý navrhujeme do dvoch rokov od nadobudnutia účinnosti tejto novely, čo považujeme za dostatočné obdobie na realizáciu zmien.
Pripomienka k §60f ods.4:
V súlade s pripomienoku k §28a žiadame odstrániť povinnosť ukladať elektronické rozhodnutia do nového registra. Súhlasíme s prechodným obdobím na sprístupnenie elektronických rozhodnutí na zdieľanie, avšak žiadame skrátiť ho na najviac 2 roky od nadobudnutia účinnosti tejto novely. Máme za to, že tento čas je pre OVM dostatočný na implementáciu rozhraní takéto zdieľanie umožniť, a to aj vzhľadom na existenciu centrálnych nástrojov pre zdieľanie údajov verejnej správy už v súčasnosti (napr. štandardy formátov, MÚK / modul integrácie údajov). Ďalej navrhujeme, aby OVM bola uložená povinnosť vykonať zaručenú konverziu a sprístupniť na zdieľanie aj každého rozhodnutia vytvoreného v listinnej forme, ktorého zdieľanie bude prostredníctvom mechanizmu zdieľania údajov vyžiadané zo strany iného OVM.
1 Like
Áno, presne tak. Aj keď ja by som nehovoril o “častiach podania”, ale skôr o “príprave podania” a “vykonaní podania” - viď. aj čo píšem k §24.
Myšlienka je to dobrá, ale nepatrí do zákona o eGov, ale do pripravovaného zákona o ITVS - takto nám to aj konzistentne už dva roky na sekcii hovoria.
Ku “častiam” formulára ešte jedna poznámka: veď pozrime sa čo sú dnes najťažšie veci pri výrobe nových formulárov a ich používaní.
Pokiaľ ja viem, tak ťažké sú:
-
v XSLT robiť vizualizačné transformácie, najmä do PDF - toto však vôbec nie je potrebné, spojili sa tu dve veci: a) chcem si vytlačiť čo elektronicky podávam + b) chcem si vytlačiť formulár ktorý potom podám listinne. Iba pri b) je nevyhnutné tlačiť do graficky presne daného (presnosť na pixel/milimeter) formátu, avšak pri b) nie je potrebné aby táto transformácia bola súčasťou autorizovaných častí. Skrátka pre vizualizáciu na tlač treba zmeniť pravidlá.
-
Doťahovanie údajov do formulára a validácie - toto vôbec formulár nemá robiť, vykoná sa to v rámci interakcie s používateľom (čo je mimo formulára). Ak si niekto chce robiť vlastné “interaktívne vypĺňanie formulárov”, samozrejme napĺňacie a validačné služby musia byť vždy prístupné cez OpenAPI.
-
Interaktívne časti formulára, najmä buttony, rôzne rozbaľovanie sekcií atď - taktiež nie je potrebné. Interkacia s používateľom má byť mimo formulára, v ňom iba prezentujem už vyplnené údaje. Plus používateľ má k dispozícii celý “holý” formulár ak si chce robiť vypĺňanie sám.
Dajme toto preč z požiadaviek na formuláre (aj niečo ďalšie?) a podstatne sa veci zjednodušia.
Definícia aspoň vizualizačnej transformácie samozrejme musí zostať súčasťou formulára - presne ako @kyselat píše, WYSIWYS musí byť zachovaný . Pokiaľ však viem, transformácia do HTML nie je až taký problém. Keď sa tieto veci štandardizovali, ja som navrhoval, aby bolo možné transformáciu písať v Javascripte : každý má na to engine (v browseri), má to dobrý sandbox, je k tomu kopa knižníc. Stále je možné XSLT opustiť.
3 Likes
Co napr. formular osvedcovacej dolozky pre konverziu z el. formy do listinnej. OVM vyplni a potrebuje to samo vytlacit. Mozno by sme nasli prikladov viac. Ak uz mam formular, neviem si predstavit, ze by nebolo zadefinovane, ako ma pri tlaci vyzerat. Treba mysliet aj na prakticke pouzitie. Aj ked je vznesenym cielom bezpapierovy obeh, to, ze si dokumenty v nejakej faze chcem vytlacit (ked uz pre nic ine, tak pre vlastnu potrebu pri spracovani), je bezna vec, niekedy je to prakticke.
Naplnacie a validacne sluzby mozu byt pristupne cez OpenAPI, ale ak je zamerom navrhovatelov novely, aby sa formular vyplnal rovnako na UPVS a na rezortnom portali, potom volanie OpenAPI niekto na UPVS musi oprogramovat rovnako, ako to urobil na rezortnom portali. Otazka je, ci je poziadavka navrhovatelov zmysluplna. Ja o tom presveceny nie som. Podla mna to znamena dalsie investicie bez jasneho prinosu pre obcana. Osobne mi je jedno, kde formular vyplnim, ci uz na UPVS alebo rezortnom portali, ak ho viem najst. Ako bolo vyssie, prinosom pre obcana je nevyplnat a neprikladat to, co uz stat ma. Tam treba smerovat programatorske kapacity a peniaze a nie na taketo cisto technicke prerabky. Ak uz stat nieco/nejaky sposob schvalil, nech sa toho drzi, pokial nejde o kriticku vec. Inak sa zbytocne minaju peniaze, cas a zvysuje sa aj neistota vsetkych zucatnenych subjektov.
Tu sú za mňa pripomienky k časti I. po §24.
Pripomienka k §6 ods. 6 (bod 8):
Navrhujeme tento bod vypustiť.
Odôvodnenie:
Úlohou špecializovaných portálov je práve poskytovať pridanú hodnotu pri poskytovaní elektronických služieb vyplývajúcu z špecifického kontextu ktorý pokrývajú. Porovnateľné možnosti nie je možné realizovať pri generickom prístupe ku službám prostredníctvom ústredného portálu. Naopak, v súlade s rozpracovaním strategickej priority NKIVS Integrácia a orchestrácia, je poskytovanie plnohodnotnej elektronickej služby prioritne orientované na agendové systémy / špecializované portály, ktoré budú samozrejme tesne integrované s centrálnymi komponentami.
Pripomienka k §10 ods. 11 písm. e):
V písm. e) za slová „a jednotný spôsob poskytovania údajov“ doplniť slová „z informačných systémov v správe orgánov verejnej moci, najmä“.
Odôvodnenie:
Zdieľanie údajov je dôležité nielen pre referenčné údaje/registre.
Pripomienka k §10a (bod 17):
Navrhujeme ods. 1 vypustiť. V ňom definovaný pojem „vládny cloud“ nie je v zákone nikde ďalej spomínaný.
Naopak, v ods. 2 definovaná „vládna cloudová služba“ zjavne nie je v zákone chápaná iba vo väzbe na „vládny cloud“, keďže podľa ods. 3 je umožnené aj používanie služieb prevádzkovaných mimo VS – čo považujeme za správne. Súčasne aj výnos o štandardoch ISVS predpokladá možnosť použitia cloudovej služby od ktoréhokoľvek poskytovateľa, ak splní požiadavky štandardov.
Ďalej navrhujeme vypustiť ods. 5. Požiadavka na využívanie iba vládnych cloudových služieb nemá žiadne opodstatnenie, je v rozpore z princípmi hospodárnosti využívania verejných zdrojov, súčasným stavom využívania IT služieb vo VS a aj v rozpore s aktuálnymi trendami v IT sektore. Náklady spojené s prevádzkovaním privátnych cloudových služieb sú v súčasnosti rádovo vyššie ako náklady spojené s použitím verejných cloudových služieb. Vzhľadom na potrebu budovania integrovaného ISVS (viď. NKIVS) sa budovaním „vlastných“ cloudových služieb prakticky stráca aspekt flexibility kapacity služieb a minimalizácie investičných nákladov.
Celkovo navrhovaný §10a podľa nášho názoru nepatrí do zákona o e-Governmente, ani nespadá pod predmet zákona v zmysle §1. Skôr je vhodné túto úpravu vložiť do zákona o ISVS, alebo pripravovaného zákona o ITVS.
Pripomienka k §17 ods. 5 a 6:
Administratívna časť vytvárania nových dátových integrácií je komplikovaná, zdĺhavá a rôzne OVM vyžadujú rôzne riešenia. Častokrát sa na poskytnutie údajov medzi konkrétnymi dvoma OVM uzatvára samostatná zmluva, a/alebo je vyžadované v príslušnej legislatíve explicitné uvedenie sprístupňovania údajov medzi týmito subjektmi. Bez zásadnej zmeny v tejto oblasti bude rozširovanie dátových integrácií napredovať iba pomaly a s vysokými nákladmi.
Preto navrhujeme vytvoriť v zákone unifikovaný generálny mechanizmus pre identifikáciu oprávnenia pre určitý OVM získavať alebo použiť dokumenty alebo údaje z IS iného OVM a za akým účelom. Prirodzeným miestom pre vedenie tejto evidencie je modul integrácie údajov (v rámci IS CSRÚ napr. takáto evidencia je vytváraná). Na úrovni zákona je napr. vhodné uviesť, že ak je oprávnenie uvedené v tejto evidencii, považuje sa nárok na sprístupnenie údajov za preukázaný (napr. pre potreby §17 ods. 6). V takomto prípade samozrejme je potrebné upraviť aj mechanizmus zápisu do evidencie.
Pripomienka k častiam zákona o autentifikácii, najmä §21:
Navrhujeme všade v zákone požiadavku na vykonanie autentifikácie neuvádzať špecificky pre eID, alternatívny autentifikátor, či autentifikačný certifikát, ale uviesť iba povinnosť na účel vykonania autentifikácie zaviesť povinnosť použiť autentifikačný modul ústredného portálu. Jednotlivé spôsoby autentifikácie majú byť pre OVM transparentné.
V súlade s predchádzajúcim odsekom navrhujeme autentifikačný certifikát uviesť ako spôsob autentifikácie v §21 ods.1
Pripomienka k §22 ods. 8:
Žiadame vypustiť tento novelizačný bod.
Odôvodnenie:
Jedným z cieľom informatizácie v súčasnosti je dosiahnuť čo najjednoduchšie a najširšie zdieľanie údajov (G2G) potrebných na výkon funkcií VS. Ak by pre každý typ údajov bolo potrebné uviesť komu môžu byť poskytnuté a v akej lehote explicitne v zákone, tieto ciele nebudú nikdy dosiahnuté.
Na splnenie cieľa uvedeného v navrhovanom ods. 8 postačí napr. vyhlásiť evidenciu alternatívnych autentifikátorov za referenčné údaje v rozsahu meno, priezvisko identifikátor držiteľa a doba jeho platnosti.
Pripomienka k §22b ods. 2:
Za slová „podľa §22aa“ žiadame vložiť text „fyzických osôb, “.
Odôvodnenie:
Vydávanie autentifikačných certifikátov aj fyzickým osobám je v súlade so zámerom novelizačného bodu č.28 a 29.
Pripomienka k §23:
V ods. 1 písm. a) bod 2 nahradiť novým znením nasledovne: „použitím na to určenej funkcie informačného systému prístupového miesta, ktorá môže byť použitá iba ak vopred bola vykonaná autentifikácia osoby ktorá autorizáciu vykonáva zodpovedajúca minimálne úrovni zabezpečenia „pokročilá“ 18a), ktorá zabezpečí uvedenie tejto osoby ako odosielateľa elektronickej správy, spojenie elektronického podania s identitou osoby vykonávajúcej autorizáciu a zachovanie väzby medzi nimi“.
Poznámka pod čiarou k odkazu 18a znie: „18a) Čl. 8 ods. 2 nariadenia (EÚ) č. 910/2014.“
Odôvodnenie:
Vytvorenie nového spôsobu autorizácie vítame a zvolenú úroveň – ekvivalent vlastnoručného podpisu – považujeme za správnu.
Uvedenie „autorizácie autentifikáciou“ je logicky nesprávne, keďže autentifikácia je v zmysle §3 písm. p) iba „preukazovaním identity“. Na tento účel sa bežne používa špecializovaná funkcia informačného systému (vyvolaná napr. stlačením tlačidla „podať“, „odoslať“, „súhlasím“ a pod.). Táto formulácia je aj v súčasnosti používaná v tomto zákone pre vyjadrenie vôle používateľa, viď. napr. §12 ods. 6, §13 ods. 3, §13 ods. 7, §14 ods. 5, §30 ods. 3.
Pri použití tejto funkcie musí byť známa osoba, ktorá autorizáciu vykonáva. To sa zaistí vykonaním autentifikácie pred použitím autorizačnej funkcie. Nepovažujeme za potrebné v zákone upraviť „ako krátko“ pred použitím autorizačnej funkcie mala byť autentifikácia vykonaná, v súčasnosti je napr. bežné že informačný systém túto dobu dynamicky zvolí na základe vyhodnotenia bezpečnostných parametrov komunikácie s používateľom.
Potrebné však je stanoviť minimálnu vyžadovanú úroveň zabezpečenia pre vykonanú autentifikáciu, keďže najnižšiu uvažovateľnú úroveň autentifikácie (charakterizovanú napr. overovaním identity osoby pri udeľovaní autentifikátora iba na diaľku) nepovažujeme za dostatočnú. V tejto oblasti navrhujeme použiť už existujúcu klasifikáciu úrovní zabezpečenia zavedenú nariadením eIDAS a z nej konkrétne úroveň „pokročilá“. Parametre tejto úrovne dávajú dostatočné záruky pre spoľahlivú identifikáciu autentifikujúcej sa osoby a súčasne pre nízku mieru rizika sfalšovania autentifikácie.
V aktuálne platných štandardoch pre ISVS je zavedená špecifická klasifikácia úrovní autentifikácie, ktoré je potrebné upraviť na kompatibilnú s klasifikáciou podľa eIDAS, alebo minimálne ju s touto klasifikáciou previazať. Predpokladáme, že úrovni „pokročilá“ v zmysle eIDAS bude zodpovedať úroveň 3 v zmysle štandardov ISVS. Použitie tejto úrovne je výhodné aj z dôvodu, že umožňuje čisto softvérovú implementáciu autentifikácie, čím sa principiálne zjednoduší realizácia autentifikácie napr. v mobilných zariadeniach.
1 Like
Ako som napísal: v tomto prípade nie je potrebné, aby transformácia do podoby na tlač bola súčasťou elektronicky autorizovaných častí.
Ťažší príklad je napr. ak chcem autorizované elektronické podanie vytlačiť. V tomto prípade by sa mala použiť transformácia, ktorá je súčasťou autorizovaných častí, default transformácia do html.
Hromadná pripomienka už je zverejnená: http://www.changenet.sk/?section=kampane&x=913119
Budeme radi ak ju podporíte.
4 Likes
no ved hej… len zasa ste zacali pouzivat take nove pojmy, ze kym clovek zisti co tym myslite, myslim ze @Lubor to popisal dobre… ja som za, nech je tam nejaka vizualizacia (aj ked pri podpise sa momentalne nepodpisuje vizualizacia, iba referencia na nu (UPVS eForm) v datach, tj. neviem vobec vyhodnotit ci by nemal byt eForm modul sucastou certifikacie pri podpisovacoch kedze garantuje jej nemennost)
Ad pojmy: mne od začiatku [života zákona o eGov] pripadá čudné, že v ňom nie je nikde “elektronická služba”. Bolo mi v 2013 vysvetlené, že tento pojem vlastne netreba, všetko je to o podaniach a rozhodnutiach. Podania sa “robia” vypĺňaním formulára. Tak to tu teda máme.
Ja si to vysvetľujem tak, že verejná správa skrátka netuší[la?] čo je to “služba”, celá interakcia naozaj vychádzala z pohľadu tetušky za okienkom, ktorej sa podajú vyplnené papiere.
Toto je jadro problému, ktorý teraz zachraňujeme.
2 Likes
Práveže tým, že sa podpisuje referencia, ktorá obsahuje hash, ak by bola jej integrita narušená, pri overovaní podpisu sa to dá detekovať. Čiže spoľahlivosť podpisu nezávisí od bezpečnosti eForm.
spoľahlivosť podpisu nie, avšak nie je isté, čo človek vidí to isté, čo videl pri podpise, pretože transformácia je v externom systéme, kde nevieme či nedošlo k jej zmene
Práveže keď si stiahnem transformáciu, vyrátam z nej hash, porovnám s tým čo je podpísané a podľa toho viem či je to to isté.
a ok… mea culpa, mas pravdu
svata pravda, … a co s tym ?