Коментар отн. раздел 2, чл 55, ал 5 софутерни лицензи

Коментар отн Раздел II, чл.55, ал 5: пропуснато е да се отбележи дали самият текст на софтуерния лиценз ще се пази като част от данните.

Някой коментари и препоръки по първата секция

На всякъде където има “XSD формат и JSON схема”, трябва да стане “XSD или JSON схема”. Така както е написано първо остава с впечатление, че трябва да присъстват и двете едновременно (не знам дали това е целта) и второ, е грешно терминологично – XSD е схема (XML Schema Definition). И тъй като JSON може да не е схема, разбирам защо думата е изрично сложена, но опростяването на изказа е важно и за точност. Например XSD формат е форматът на XSD, но не гарантира че е XSD схема. Тук очевидно се търси схемата (дефиниция на структурата на данните). Така че е добре да се отбележи, че става въпрос за схема и в двата случая. Но по важното е, дали е И или ИЛИ правилото. Имам предвид основно чл. 3, но не само. 

На Чл. 6(3) не ми става ясно какво се има предвид под идентификацията се осъществява с всяка система, с която регистърът извършва комуникация. Това взаимна (multual authentication) ли е (каквото е описано в чл.6(2)), или просто задължение да се използва TLS? Или е нещо друго? Ако е задължение да се използва TLS, то изказа е неточен и двусмислен. Трябва да се пренаправи на “Регистърът трябва да използва само криптирана и идентифицирана със сертификатите комуникация със всяка система, с която комуникира”.

Член 7(1) и 7(2) ми влизат в известно противоречие (или аз не го разбирам коректно). Вероятно 7.1 казва че достъпът трябва да е безплатен, но 7.2 казва че е гарантиран достъп само до личната информация на заявилият. Тоест не се гарантира свободен достъп до цялата информация (няма Open Data)? Или трябва да се преформулира?

7.3 е членът за който аз радетелствам изначално от много време. Обаче липсва много важен елемент от него. А именно, че програмният интерфейс трябва да бъде публично достъпен и точно документиран и същият публичен а не друг частен интерфейс трябва да се използва и от всички приложения, които работят с регистъра (за да гарантираме, че когато има бъг се поправя, както и няма скрити функции за избрани). В 7.11 се споменава за публичната документация. Но ми липсва публичната достъпност на програмният интерфейс (1) и ми липсва изискването всички приложения, които работят с регистъра да използват този публичен програмен интерфейс. Вероятно 7.4 третира публичността (но сякаш допуска да има два различни програмни интерфейса, публични и частни, което би било проблем) но е спорно.

Според мен трябва да се добави 7.12 (ако не се сложи да е 7.4 а останалите се преместят едно на долу) с текст: "Всички приложения, които ползват електронен регистър са задължени да го осъществяват чрез документираните функции на публичният програмен интерфейс от чл. 7(3)." 

Така се гарантира, че няма да има друг програмен интерфейс, както и програмният интерфейс по задължение ще трябва да е винаги коректно документиран. Ако “публичният” е проблем, то може да се махне думата.

Чл. 8.5 допуска ръчно осигуряване на данни за нуждите на регистъра или за запитване, но оставя голяма дупка. Смятам че за всяка ръчна работа, трябва да се изисква електронно проследим статус през регистъра (за да се знае какво се случва, както примерно е при пощенските услуги). Смятам че е редно да се напише изискване да има проследим статус.

Несъответствие в "Преходни и Заключителни разпоредби"

Текст в Наредбата в частта "Преходни и Заключителни разпоредби"  се позовава на Чл. 68, но такъв член липсва в самата наредба.

Потвърждение

Тъй като за дата на приключване на обществените консултации, е посочена 03.12.2016 г., а 3 декември се пада събота, моля потвърдете, че мнения и препоръки ще бъдат приемани до 5.12.2016 г., понеделник, /включително/ и така получените ще бъдат отчетени и разгледани при приемането на наредбата.

Препоръки

Уважаеми госпожи и господа,

По-долу са представени бележки по предложения за обществено обсъждане проект Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги. Искрено се надявам да бъде спазен стриктно Законът за нормативните актове и бележките да бъдат взети под внимание, тъй като проектонаредбата е практически неприложима в доста свои части – било поради противоречие с по-високи по степен нормативни актове, било поради непознаване в детайли на процесите по предоставяне на административни услуги, било поради непознаване на действащото законодателство като цяло. Има и недостатъци на юридическата техника, които обаче не са изброявани изрично, защото изложението ще стане прекалено дълго, а е необходимо да се обърне внимание на по-съществените въпроси, изложени по-долу.

1.     Чл. 7, ал. 5: Всички данни, вписани от доставчици на услуги в административния регистър, са достъпни за центровете за електронна идентификация по Закона за електронна идентификация (ЗЕИ).

Какво налага центровете да имат достъп до всички данни, вписани в административния регистър? Такава възможност не е предвидена в Закона за електронната идентификация, нито пък се налага за целите на извършване на идентификацията.

2.     Чл. 10, ал. 2 Информационните системи на други организации се вписват в отделен раздел на Административния регистър от председателя на Държавна агенция “Електронно управление” след подаване на заявление. Председателят съгласува достъпа до данните, който вписаните организации са заявили, със съответния първичен администратор.

Чл. 10, ал. 2 от наредбата или съдържа терминологична неточност или противоречи на ЗЕУ с използването на термина „други организации“. Не е ясно кои са тези „други организации“. ЗЕУ създава задължения за административните органи, лицата, предоставящи обществени услуги и лица, осъществяващи публични функции. Т.е. задълженията трябва да се отнасят до една от тези три групи – ако „други организации“ са лица, непопадащи в някоя от трите групи, тогава имаме излизане извън приложното поле на ЗЕУ, което би направило разпоредбата неприложима.

Ако тълкуваме чл. 10, ал. 2 във връзка с чл. 10, ал. 1, където са посочени  „административни органи“ и „доставчици на обществени услуги“, то тогава може да се направи евентуален извод, че става дума за лица, осъществяващи публични функции. Ако законодателят има предвид тях, трябва да използва еднакви юридически понятия и точни термини, а не произволни синоними, защото последното е в противоречие със ЗНА /изискването се учи още в първи курс на юридическите факултети/.

3.     Чл. 19, ал. 6 При изграждане или надграждане на информационни системи за предоставяне на електронни административни услуги те задължително трябва да бъдат на ниво 4, в случай, че изискват плащане, и на ниво 3 - в останалите случаи.

Разпоредбата на чл. 19, ал. 6 от наредбата противоречи на  чл. 8, ал. 2 ЗЕУ - когато резултат от услуга трябва да бъде в особена форма или представлява определено действие (като залепване на стикер например), няма как да бъде постигнато такова ниво на електронизация. Тоест ЗЕУ предвижда възможност и за по-ниско ниво на електронизация, но все пак създава задължение да има такава, за да се създаде удобство за гражданите и бизнеса. Наредбата пък се забранява такава частична електронизация. Противоречието с нормативен акт от по-висока степен би направило разпоредбата неприложима.

Препоръки продължение 1

1.     Чл. 19, ал. 7 Процесите по предоставяне на електронни административни услуги следват Методологията за усъвършенстване на работните процеси за предоставяне на административни услуги, утвърдена с Решение № 578 на Министерския съвет от 30 септември 2013 г.

Не е съвсем точна формулировката на чл. 19, ал. 7 от наредбата - Методологията за усъвършенстване на работните процеси за предоставяне на административни услуги предписва механизъм за подобряване на работните процеси /анализи, които трябва да бъдат извършени, действия, които трябва да бъдат предприети/, но не и самия процес по предоставяне на административни услуги. На практика препращането към нея не създава каквито и да било задължения за администрациите във връзка с предоставянето на електронни административни услуги.

2.     Чл. 20, ал. 5  Заявлението се счита за получено от доставчика в момента на постъпване в информационната му система, удостоверен чрез електронни времеви печати по Раздел 6 от Регламент (ЕС) № 910/2014, а в случай на подаване по електронна поща - от момента, в който длъжностно лице го въведе във вътрешната система за електронен документооборот.

Според втората хипотеза на чл. 20, ал. 5 от наредбата  – за време на получаване на заявление по електронна поща да се счита времето на въвеждането му в деловодната система създава сериозна възможност за злоупотреби и нарушаване правата на заявителя – деловодител може умишлено да реши да въведе заявлението 3-5 или 7 дни след като е получено на електронна поща, а през това време ще си текат срокове за заявителя, които могат и да преклудират правата му.

Разпоредбата на ал. 5 противоречи и на европейското законодателство в тази връзка, а също и на национален нормативен акт от по-висока степен, а именно чл. 10 от ЗЕДЕП. 

Препоръки продължение 2

1.                 Разпоредбата на чл. 21, ал. 1 от наредбата противоречи на чл. 22, ал. 5 от ЗЕУ. Чл. 22, ал. 5 от ЗЕУ (за която е спорно колко добро законодателно решение е) предвижда е-изявления да се подписват с усъвършенстван е-подпис, само когато физическите лица, са се идентифицирали електронно по реда на ЗЕИ. Във всички останали случаи се изисква КЕП. Наредбата създава възможност за подписване с усъвършенстван подпис, без да поставя каквито и да било допълнителни изисквания в тази връзка. Посочената формулировката на разпоредбата оставя нерешен въпросът може ли заявление да се подписва с усъвършенстван електронен печат или винаги ще се изисква квалифициран такъв.

В допълнение целият чл. 21 изобщо не предвижда възможност за подписване с електронни печати, което означава, че представител на юридическо лице не може да подпише заявление /изхождащо от дружеството/ с е-печат, издаден на юридическото лице, а ще трябва да го подпише задължително с личния си електронен подпис на физическо лице, което е в пълно противоречие с изискванията на Регламент 910/2014 г. /което впрочем е и пропуск на ЗЕУ/.

2.     Чл. 24 е-плащания

·       Чл. 24, ал. 4 от наредбата - Не е ясно какъв е този „централизиран компонент за електронни плащания“ – кой носи отговорност за изграждането и поддържането му, на какви технологични изисквания трябва да отговоря, как става свързването с него, безплатно ли е, не е ли?

·       Чл. 24, ал. 5 от наредбата преписва много неясен текст /затова и недействащ и към момента/ текст от сега действащата Наредба за електронните административни услуги. Не е ясно кой има задължението на впише тази услуга в Административния регистър. Само една услуга ли ще бъде вписана или множество отделни услуги, например ще има само една услуга плащане на данъчни задължения или ще има услуга – плащане на местен данък, плащане на данък към НАП, плащане на мито или ще има още по-детайлно делене в зависимост от вида данък. Нелогично би било да се впишат като една и съща услуга плащане на данък и плащане на имуществена санкция като публично-правно задължение на юридическо лице, защото двете вземания имат много различен режим и правна същност (най-малкото върху глоби и санкции не се начисляват лихви).

·       Чл. 24, ал. 7 от наредбата противоречи на Закона за платежните услуги и платежните системи – няма как доставчик на е-административна услуга да получи потвърждение от платежна система за извършено плащане, тъй като доставчиците на е-административни услуги нямат право да бъдат участници в такива системи и не е предвидено да си комуникират с тях. Чисто като изказ е некоректно и препращането към ал. 1 на чл. 24 /“система по ал. 1“/, тъй като в ал. 1 изобщо няма такава система, а е цитиран само Закона за платежните услуги и платежните системи.

Като цяло само един член от наредбата изобщо не е достатъчен да уреди електронните плащания при предоставяне на електронни административни услуги. Необходима е уредба, която детайлно да регламентира задълженията на всички участници в процеса и тя да бъде съобразена с особеностите на дейността на платежните оператори, които са подчиняват на друго, специално законодателство. Необходимо е тази регламентация да се съгласува и с Министерство на финансите, както и с БНБ.

Липсва регламентация и на друг, много важен въпрос, свързан с административната тежест върху гражданите и бизнеса – е-плащания с банкови карти. Ако се използва такава карта на физически ПОС-терминал, платецът не дължи никаква такса за превода – плаща само цената на административната услуга. Ако обаче платецът използва виртуален ПОС-терминал, освен таксата за услугата, се дължи и такса за извършване на превода, която се плаща на доставчика на платежни услуги. Това неравноправно третиране е необходимо да бъде преодоляно, и то на законово ниво, а не с подзаконов нормативен акт.

Не е ясно и как ще бъдат налагани глобите предвидени в чл. 63 от ЗЕУ, ако администрация не осигури възможност за разплащане с банкови карти например – кое ще е длъжностното лице, което ще бъде глобено, за всяка услуга, извършена от администрацията ли ще му бъде наложена глоба?!

Не на последно място – чл. 12, ал. 5 от ЗЕУ предвижда, че „начинИТЕ“ на е-разплащания, се определят с наредбата по чл. 12, ал. 4 ЗЕУ. Настоящия проект обаче не определя никакви „начинИ“, а само най-общо посочва, че се използват „електронни платежни инструменти“, без да дава каквато и да било регулация.

Препоръки продължение 3

1.                 Чл. 25, т. 4 от наредбата предвижда, че когато съществуват нормативни изисквания за деклариране на обстоятелства, декларирането няма да става с прикачване към заявлението на отделен документ, а декларацията ще бъде под формата на електронен шаблон, който ще се подписва заедно със заявлението. Подобно решение е много практично, но е в пълно противоречие със специални закони за предоставяне на редица услуги, които изискват определени обстоятелства да се декларират в лично качество. Например: ако аз съм управител на ООД и упълномощя адвокат да попълни заявлението за получаване на някакво разрешително на ООД-то, то няма как декларация, която по закон трябва да бъде подписана от мен като управител, да бъде попълнена от адвоката ми и подписана от него, с неговия електронен подпис. Ако това се случи, ще означава, че декларация изобщо не е подадена и ще бъде изискана допълнително от административния орган.

Важно е да се подчертае, че предложеното техническо решение е практично, но ако законодателят иска да бъде приведено в изпълнение, то трябва да бъде заложено в ЗЕУ, а не в наредба, тъй като при противоречие между настоящата наредба и специалните закони, изискващи подписване в лично качество, ще се прилагат законите като по-висши по степен нормативни актове.

2. Чл. 26, ал. 2 от наредбата предвижда една обща споделена инсталация за предоставяне на най-често използваните общински и областни електронни административни услуги. Означава ли това, че една община, която реши да внедри своя електронна административни услуга, ще предостави системата си за ползване от всички останали администрации (съответно и една община ще плати за цялата система)? Няма никакви гаранции, че дори и да бъде спазван референтния модел, той ще отговоря на административните процеси в администрацията на всяка една община, защото няма как големите общини като Столична например, да имат един и същи модел на работа с някоя малка община.

3.      Чл. 27 – Системи за сигурно електронно връчване

Чл. 27 от наредбата се опитва да даде някаква регламентация на системите за е-връчване, но всъщност нито тук, нито в където и да било в наредбата дава отговор на въпроси, на който трябва да бъде дадена регламентация, съгласно чл. 26, ал.  от ЗЕУ, а именно: „Получателят на електронната административна услуга е длъжен да посочи електронен адрес за уведомяване съгласно изискванията, определени в наредбата по чл. 12, ал. 4“. Такива изисквания в наредбата липсват, въпреки че трябва да ги има, за да има съответствие със ЗЕУ. В момента е налице законодателна празнина по този въпрос.

Препоръки продължение 4

1.                 Чл. 32, ал. 7 от наредбата създава задължение административните органи да поддържат „бази данни за знание“ – не е ясно обаче на какви изисквания трябва да отговорят тези бази данни, кой може да има достъп до тях. Последното е особено важно, тъй като смисълът на добрите практики е да бъдат споделяни, надграждани и мултиплицирани и в други административни органи.

2.                 В чл. 38, ал. 3 и ал. 4 от наредбата е предвидено „при изготвяне на задания за провеждане на обществени поръчки …. администрациите да следват образеца в Приложение II“, а „при вътрешно изграждане и надграждане информационни системи и софтуерни компоненти, служителите на администрацията да следват максимално изискванията на образеца в Приложение II“ /тук е пропуснат предлог, но е техническа грешка, която вносителите на проекта, вярвам, че ще коригират/. При тълкуване на посочените две алинеи може да бъде направен извод, че когато външни за администрацията лица изграждат информационни системи, те трябва да се придържат стриктно към изискванията в образеца (защото не могат да се отклоняват от заданието), а когато служители в администрацията изграждат такива системи, те може да се отклоняват. В каква степен е възможно отклонение не е ясно, защото разликата между ал. 3 и ал. 4 е само думичката „максимално“, която няма ясни параметри. Не е ясно дали в ал. 4 е употребена умишлено, с идеята да очертае режим, по-свободен от този в ал. 3.

При прилагането на наредбата обаче много по-сериозен проблем ще бъде изискването за максимално следване на образеца – причината е, че повечето администрации имат свои специфики в административните процеси, породени от разнообразието на специалните закони, които изпълняват; имат различни нужди, които са динамични и сляпото спазване на типов шаблон, не само няма да усъвършенства работните процеси, но може ще доведе и до противоречия със специалните закони, уреждащи дейността на дадената администрация.

Не на последно място посоченият образец не е напълно съобразен и със изискванията на ЗОП по отношение на техническите задания, изисквания към тях и показатели, по които се оценяват.

3.                 Чл. 37, ал. 1 от наредбата предвижда, че електронните документи се подписват с електронен подпис, издаден  по реда на Наредбата за удостоверенията за електронен подпис в администрациите – необходимо е прецизиране на разпоредбата, с което да стане ясно, че изискването е само за е-документи, изходящи от администрациите (видно и от името на наредбата, към която се препраща). Най-добре е уточнението да се извърши още в заглавието на чл. 37, защото така, както е формулиран текста в момента, изглежда, че изискванията в него се отнасят за всякакви е-документи, вкл. и тези, произхождащи от гражданите и бизнеса.

Препоръки продължение 5

1.                 Чл. 43, ал. 2 от наредбата предвижда, че на архивиране подлежат е-документи, по-стари от две години, освен ако в закон не е предвидено друго. Препоръчително е разпоредбата да се прецизира като се съобрази срокът на валидност на различните документи – например има лицензи, разрешителни и т.н., които имат срок на валидност 3 години, 5 години и т.н. Ако те са издадени като е-документи, е необходимо да се прецени дали е целесъобразно да бъдат архивирани, докато все още са валидни.

2.                 Чл. 44 от наредбата, а и в други нейни разпоредби се предвижда компютърните програми за информационните системи на административните органи да бъдат с отворен код, който да бъде публично достъпен за всякакви лица, без да е нужно тези лица да се идентифицират, да са на територията на Република България, да искат някакви разрешения или да отговорят на каквито и да било други изисквания. Т.е. всеки терорист, който си поиска, ще може да види каква е архитектурата и на какъв принцип работят ЕСГРАОН, информационни системи на НАП и Агенция „Митници“, информационни системи в здравеопазването, информационни системи, съдържащи информация за опасни вещества, за различни видове производства и т.н., което не само че прави всички системи в държавата изключително уязвими, но си е открита покана към всички желаещи да се пробват да ги „разбият“. Покана за един ден да сринат цялата държава само като блокират 5 или 10 ведомства….. или пък дълго и сигурно да си източват/подменят данни, манипулират хора, само защото като знаят кода на системите, могат съвсем ефективно да избегнат анонимизирането на публичната информация и да черпят всичко с „пълни шепи“ направо от източника.

Аргументи, че отвореният код прави системите по-сигурни, защото всеки ще може да следи за „бъгове“ са абсолютно несъстоятелни - в областта на главоломно развиващите се информационните технологии, дори и нещо да е много добро и сигурно днес, няма никакви гаранции, че ще бъде такова след 2 седмици, а до 3 месеца от създаването му, вече ще има измислена технология за разбиването му.  А нито ДЕАУ, нито административните органи могат да отделят финансов и човешки ресурс всеки месец да тестват, доработват и надграждат системите.

Изискването за отворени и публично достъпни сорс-кодове на информационните системи в административните органи е недостатък не само на наредбата – той е заложен и в ЗЕУ. Никъде обаче няма такова изискване и такава практика по отношение на държавните органи. България е единствената европейска държава, която сама и без някой да поиска, сваля доброволно всички защити пред държавната администрация. НЯМА ПОДОБНО ИЗИСКВАНЕ И В ЕВРОПЕЙСКОТО ЗАКОНОДАТЕЛСТВО – НИТО НА НИВО РЕГЛАМЕНТИ, НИТО НА НИВО ДИРЕКТИВИ, НИТО В НЯКАКЪВ ДРУГ АКТ. Нещо повече, в The European eGovernment Action Plan 2016 – 2020, приет през април 2016 г. се говори, че администрациите трябва да отворят техните данни и услуги към други администрации, а по отношение на бизнеса – само доколкото е възможно. Няма дори и намек за отворени и публични достъпни изходни кодове на информационните системи в административните органи. Европейската концепция за отворени данни и отворено управление (https://ec.europa.eu/digital-single-market/open-government ) изобщо не изисква използването на отворени кодове на информационните системи. Останалите страни-членки на ЕС, както и органите на съюза ясно съзнават каква заплаха би било такъв подход не само за правата на гражданите, но и за националните  сигурност и суверенитет и за общоевропейските такива.

Защо българският законодател единствен е възприел подхода на „разградения двор“ не е ясно. Най-очевадните възможности са две – или както винаги някой е чел-недочел европейското законодателство и политики и се е втурнал да твори национална правна уредба, или още по-лошият вариант – под нечие давление, умишлено създава заплаха за сигурността и правата на собствените си граждани и държава.

Препоръки продължение 6

1.                 Чл. 53 от наредбата, изискващ съгласуване на вписванията в регистъра по чл. 51, включително и на техническите задания за проекти (чл. 52 от наредбата), отстъпва от основен принцип, залегнал в ЗЕУ, че една и съща информация не може да се събира повторно, когато вече е събрана от един държавен орган. Според ЗОП техническите задания на проекти в административни органи се публикуват в регистъра на АОП. В регистъра по чл. 51 от наредбата те ще бъдат събирани отново, без да е ясно в кой регистър /по чл. 51 или в този на АОП/ трябва да се извърши първичното вписване. Предвидените в чл. 53 срокове за вписване и обжалване на вписване в регистъра по чл. 51 не са съобразени с изискванията на ЗОП и Закона за управление на средствата от Европейските структурни и инвестиционни фондове, където сроковете са доста по-кратки.

2.                  Недостатък на целия проект е законодателната празнина, която създава с отмяната на Наредбата за електронните административни услуги – макар и отделни нейни разпоредби да са преписани/преработени разпокъсано в настоящия проект, липсва цялостна регламентация на електронните административни услуги, които ще бъдат предоставяни на гражданите и бизнеса и информационните системи, които се използват за тяхното предоставяне. При внимателен прочит на настоящия проект на наредба става ясно, че са регламентирани детайлно удостоверителни услуги, има и изисквания към системите за документооборот на административните органи, но на много места липсва задължителна уредба и изисквания към информационните системи за предоставяне на административни услуги към гражданите и бизнеса, за процесите по предоставянето им и т.н. Дори и някъде да има частична регламентация, тя изобщо не е систематизирана.

3.                  Параграф 5 от наредбата предвижда за идентификация на физически лица да се прилага и прочитане на личен идентификатор от квалифициран електронен подпис, но само в срок до 1 август 2018 г. Това законодателно решение означава, че след 1 август 2018 г. заявителят ще трябва да използва първо, за да влезе в дадена информационна система, удостоверение за електронна идентичност, а след като попълни заявлението си, да използва удостоверение за усъвършенстван/квалифициран е-подпис, за да подпише заявлението си. Какво налага да се задължат заявителите да си закупят /съответно и платят/ две удостоверения – едно за е-идентичност и друго за е-подпис?! Идентификация еднозначно може да се извърши и с прочитане на уникален идентификатор от квалифициран електронен подпис /КЕП/, каквато е практиката и към момента. Ако заявителят е съгласен да се извърши идентифицирането му чрез данни от КЕП, няма никаква пречка за това, включително и Регламент 910/2014 година позволява такава практика. Българското законодателство, вкл. и ЗЕУ, позволя идентификация, освен чрез издаденото удостоверение за е-идентичност и „по други методи, определени със закон“ – ЗЕУ може да предвиди такъв друг метод. Поставяйки необосновани допълнителни технологични и финансови пречки пред обикновените граждани по повод използването на електронни административни услуги, законодателят не само че не облекчава гражданите, бизнеса и не подпомага развитието на електронното управление, но и практически преориентира средностатистическия потребител /не представители на бизнеса/ към традиционния хартиен начин на административно обслужване, защото там няма да му се налага да прави излишни разходи за закупуване на n-на брой устройства и удостоверения.  

Относно някои неточности и въпроси при четене

Относно Регистър на регистрите

В Раздел І Регистри за оперативна съвместимост е посочен чл. 2 Регистър на регистрите.

В ЗЕУ раздел Регистри за оперативна съвместимост не се предвижда такъв регистър. Няма го предвиден и никъде другаде в закона.

Относно регистър на стандартите

В Наредбата Чл. 4 Регистърът на стандартите е информативен списък ...

докато в ЗЕУ изрично е записано че е единна централизирана електронна база данни, управлявана от информационна система.

Относно идентификация на регистрите

Не намирам смисъл в отделна уредба по чл. 6 и по чл. 10. Реално идентификацията на регистрите е пак идентификация на информационната система на регистъра.

Относно т.нар. централен компонент

В чл. 7, ал. 8 се говори за някакъв централен компонент. Какъв е този централен компонент? Някакви изисквания към него, кой ще го разработва? Това същия компонент за който се споменава при плащанията ли е?

Относно времеви печат при всеки достъп до регистър

В чл. 7, ал. 10 е предвидено удостоверяване на време на всеки достъп по всеки регистър чрез времеви печат. Услугата по удостоверяване на време чрез времеви печат е платена и може да се окаже доста сериозно перо за популярни регистри като Търговски регистър или Регистър Булстат. А и какъв е смисъла от това удостоверяване за всеки достъп? На редица места в наредбата се въвежда ползването на времеви печат, което е добре за организациите които ги предоставят, но доколко е целесъобразно в много от случаите?

Относно резултата от удостоверителна услуга

Резултатът по чл. 9, ал. 3 под формата на електронен документ ли ще бъде, който да може да бъде получен от заявителя? Би било добре ако изрично е казано да бъде под формата на електронен документ, както и относно срок за съхранение.

Относно технически протокол за обмен на документи по чл. 18

Добре е да има указан срок в който да се определи от председателя на ДАЕУ. Впечатлението ми е, че когато няма указан срок, в тези случаи никога не се стига до изпълнение на съответното указано действие.

Относно грешка в цитиране

В чл. 34, ал. 1 се цитира чл. 16, ал. 1 (явно се има предвид чл. 18).

Също чл. 56, ал. 1 неправилно се цитира чл. 49, ал. 1 (явно се има предвид чл. 55)

В чл. 63, ал. 3 се цитира изискванията на глава ... (неизвестно коя)

Относно образеца по Приложение ІІ

Вероятно не е добра идея да го има като част от Наредба, тъй като ще доведе до механичното му копиране за всяко техническо задание.

Относно изискването за лиценз и отворен код

Залагането на лиценз като EUPL (или някой от другите по чл.- 44, ал. 3) означава и отказ от гаранции и отказ от отговорност на разработчика. https://joinup.ec.europa.eu/sites/default/files/eupl1.1.-licence-bg_0.pdf

Отворен код за всеки проект!? Има много аргументи против, но без да има някакъв по-широк консенсус вече а сложено в ЗЕУ. Би имало смисъл за някои разработки, най-вече които да могат да се преизползват на други места. И преди изменението на ЗЕУ не бе особена пречка, доколкото в повечето случаи администрацията възложител е придобивала собственост върху разработката (т.е при желание е можела да сподели резултата с друга администрация или да направи публичен кода на разработката).

Относно информационна сигурност

чл. 45 – не трябва ли да бъде част от наредбата уреждаща мрежовата и информационна сигурност?.

Относно астрономическото време по чл. 46

Добавено е отчитане с точност до милисекунда, което е в противоречие на ЗЕУ (в закона е предвидено да бъде до секунда).

И тук както и на други места затруднява липсата на последователност в ползваната терминология – чл. 1, ал. 1, т. 1 от наредбата, а така също и в закона се говори за единно време. В НЕАУ към момента е пък единно астрономическо време.

Относно легални дефиниции § 1, т. 8-15

Няма смисъл от такива дефиниции (едва ли ще има нужда от такива доуточнения и посочване на линкове къде се намират текстовете на лиценза в момента).

Относно целият текст на наредбата

Добре е да се пусне един спел чек на текста, а най-добре да се даде на коректор. Виж например организаци (чл. 1, ал. 1, т. 8), услугии (чл. 1, ал. 2),  методитчески (чл. 3, ал. 5),  минмална (чл. 6, ал. 2) ......

Становище по проект на Наредба за общите изисквания към ИС, регистрите и ЕАУ - 1

След като подробно се запознахме с проекта на Постановление на Министерския съвет за приемане на Наредба за общите изисквания към информационните системи, регистрите и електронните административни услуги (Наредбата) и доклада към него, предоставяме на Вашето внимание препоръки за подобрение на Наредбата, за да може тя ефективно да изпълни предназначението си.

Една от целите на Наредбата е да позволи максимално кратък и удобен процес по заявяване на електронни услуги, заплащането на съответните такси и получаване на резултата от тяхното изпълнение. Заплащането на таксите за административни услуги е уредено в чл. 24 от Наредбата. Изпитаната ни успешна практика и опит във връзка с плащането на такси за административни услуги категорично доказаха, че за тази дейност е необходима подробна и детайлна регламентация на правата и задълженията на всички субекти, участващи в процеса на плащане, защото в момента има много неясноти, липсва регламентация, което довежда до плащания по два основни начини – плащане на каса в дадената администрация за по-малки суми или плащане на таксите чрез превод на каса в банка. Това препятства ползваемостта на електронните услуги, води до ненужен разход на време и средства както за административните органи, така и за получателите на услуги и в крайна сметка пречи на качеството на административното обслужване като цяло.

Становище по проект на Наредба за общите изисквания към ИС, регистрите и ЕАУ - 2

Решението на посочените проблеми беше  формирано и реализирано в изпълнение на Договор № Д-18/15.04.2015 г.: „Надграждане на системата за електронни разплащания към централната и местна администрация, чрез разработване на единна входна точка за използване на наличните инструменти за плащане в Р. България и разработване на услуга за удостоверяване на време”, който договор беше сключен в изпълнение на Дейност 6 от проект „Надграждане на съществуващите и изграждане на нови централни системи на електронното правителство с оглед на усъвършенстване на информационно-комуникационната среда за по-добро административно обслужване на гражданите и бизнеса” с рег. № К 13-32-1/30.09.2013 г., осъществяван с финансовата подкрепа на Оперативна програма „Административен капацитет“ с възложител Министерство на транспорта, информационните технологии и съобщенията. Изпълнител на договора е консорциум ТАКС МИ, като представляваното от мен дружество е водещ партньор в него. Договорът приключи и изпълнението му беше прието от възложителя в средата на м. декември 2015 година. В резултат от изпълнението на горецитирания договор бяха разработени:

1. Единна входна точка за електронни разплащания в държавната и местната администрации (Среда за електронни плащания);

2. Услуга за удостоверяване на време (TimeStamp).

И двата продукта бяха успешно внедрени в пилотни администрации, а също така демонстрираха и възможността си за успешна комуникация и взаимодействие със софтуерните решения, разработени в изпълнение на останалите дейности по проекта за надграждане на съществуващите и изграждане на нови централни системи на електронното правителство. Сериозен интерес за включване към Средата за електронни плащания беше проявен както от различни административни органи, така и от почти всички доставчици на платежни услуги в Република България. Единствената пречка за масовото им включване в Средата за електронни плащания беше и все още е липсата на приета нормативна уредба, подробно регламентираща реда и начина за включване в Средата за електронни плащания, правата и задълженията на всички участници в нея. Предложения за приемане на такава уредба (създаване на нова и изменение на съществуваща) беше направена в изпълнение на посочения проект – проведените тогава анализи, консултации с всички заинтересовани страни очертаха параметрите на необходимата регламентация, която е невъзможно да се изчерпа само с един-единствен член от предложената Наредба. Общи насоки за въпросите, които задължително се нуждаят от нормативна регламентация, възможните начини за плащане, както и други подробности във връзка с действието на Средата за електронни плащания към доставчици на електронни административни услуги може да намерите на следния адрес: https://pay.egov.bg/.

Становище по проект на Наредба за общите изисквания към ИС, регистрите и ЕАУ - 3

Вярваме, че след като се запознаете с Единната входна точка за електронни разплащания в държавната и местната администрация и услугата за удостоверяване на време, ще се убедите в необходимостта от тяхното масово използване при предоставяне на административни услуги. И двата продукта отговорят в пълна степен на действащата нормативна уредба, гарантират изпълнение на нуждите, мотивирали изготвяне на Наредбата, а също и гарантират декларираните цели на реформите в електронното управление през последната повече от година.

До момента по-широката ползваемост на двата продукта беше възпрепятствана от структурните и организационни промени в Министерство на транспорта, информационните технологии и съобщенията и създаването на Държавна агенция „Електронно управление“ (ДАЕУ). От месец декември тази година ДАЕУ вече би трябвало да започне реално да изпълнява своята дейност и задълженията си като орган, отговарящ за развитието на електронното управление в Република България. Последователната държавна политика и приемствеността в управлението също налагат реалната експлоатация на успешни, работещи решения, водещи до удобство и по-голяма ползваемост на електронните услуги. Именно такива решения са Средата за електронни плащания и услугата за удостоверяване на време. Не трябва да забравяме и необходимостта от осигуряване на устойчивост на резултатите по проекти, финансирани с европейски средства и отговорността към обществото за ефективно и ефикасно изразходване на финансовите ресурси. Икономическата ситуация в страната едва ли позволява да бъдат изоставяни вече изготвени, работещи, иновативни решения, които пестят време и средства на администрацията, гражданите и бизнеса и които водят до по-голяма проследимост и събираемост на публичните задължения. Подобно поведение е неприемливо и от позицията ни на отговорен член на Европейския съюз – наше задължение е не просто да спазваме принципите и политики на разходване на средства от европейските структурни и инвестиционни фондове. Наше задължение е и да не изоставаме от европейските тенденции и особени тези, насочени към трансформация на управлението в такова, което е по-близо до гражданите и което е в услуга на обществото.

Надяваме се, че отправените препоръки ще бъдат взети под внимание при изготвяне на Наредбата. Оставаме на разположение за допълнителни въпроси, коментари и др., включително и да предоставим наличния в Министерство на транспорта и информационните услуги проект за нормативна регламентация на плащанията при предоставяне на административни услуги, изготвените в изпълнение на Договор № Д-18/15.04.2015 г. „Надграждане на системата за електронни разплащания към централната и местна администрация, чрез разработване на единна входна точка за използване на наличните инструменти за плащане в Р. България и разработване на услуга за удостоверяване на време”.