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

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

Това са индикации за проблеми, свързани както с работата на МВР, така и с работата на Министерство на електронното управление – МЕУ е органът, натоварен с политиката по електронна идентификация и фактът, че не е упражнен контрол и не е наложена съвременна визия, води до риск отново да нямаме адекватна електронна идентификация.

Ще ползвам тези проблеми да обърна внимание и на това, което като цяло се случва в Министерството на електронното управление.

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

Като започнем от абдикацията на МЕУ от електронната идентификация (илюстрирано от отговорите на МВР), от прозрачността (напр. на данните за плащанията в СЕБРА), от хибридните заплахи; минем през не докрай обмисленото съгласуване на процесите с електронните бележки и рецепти, през липсата на напредък по невидимите, но важни второстепенни задачи, без които не може, и стигнем до тормоза на служители с постоянни проверки на инспектората и съответното напускане на служители (видно от отговори на други парламентарни въпроси).

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

В светлината на горните проблеми все по-малко смятам, че МЕУ ще се справи със задачите и с очакванията, които всички имаме към него. Това, разбира се, не освобождава МВР от отговорност за електронната идентификация, но то е само част от картината. Длъжен съм да предупредя за тези рискове.

Искам да благодаря на служителите в министерството на електронното управление, които продължават съвестно да изпълняват задълженията си въпреки дисциплинарния произвол и хаоса.

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

А по темата с електронната идентификация – разчитам на експертите в МВР да защитят обществения интерес, да изискат спазването на закона и въвеждането на съвременни функционалности. Иначе рискуваме да стигнем до същия казус като с тол-системата и да се чудим „къде е кодът“. Или дори по-лошо – никой да не търси кода, защото системата не се ползва.

За да се върнем в правилния път, предлагам (най-малко) следното:

1. МЕУ и МВР да определят съвместно какво трябва да получат гражданите от електронната идентификация – според мен това трябва да е мобилно приложение, с което да могат да се идентифицират без непременно нужда от нов личен документ, с ниво на осигуреност „средно“ по подразбиране, и „високо“ при регистрация с нова лична карта или след посещение на място.

2. Да бъдат наваксани забавянията по проектите по плана за възстановяване и устойчивост.

3. МЕУ и МФ да приемат изменения в наредбата за СЕБРА за регулярен експорт на данни за плащанията от държавата чрез СЕБРА (оставих проект за такова изменение още миналата година).

4. МЕУ да съдейства на МОН и МЗ за въвеждане на възможност за извинение на отсъствия по преценка на родител до определен брой дни, както и да се работи по доклада, който подготвехме преди година и половина, за отпадане на всякакви бележки и хартийки в системата на образованието.

5. МЕУ да координира въвеждането в продукционна среда адаптерите за обмен на данни с новия ТЕЛК-регистър и нови адаптери за регистрите на Агенция по вписванията (нещо, по което беше начертан план преди година и половина)

6. С проекта на устройствен правилник на МЕУ да не бъдат заличавани функциите, свързани с дезинформация,  хибридни заплахи и стратегически комуникации.

7. Да бъде извършен анализ на подзаконовата нормативна уредба, която противоречи на последните изменения в Закона за електронното управление.

8. Да бъде приета подзаконова уредба и съответните правила за използване на държавния облак, държавната мрежа и защитения интернет възел – особено облакът в момента почти не се използва заради липсата на подходящ процес.

9. Да бъде спрян тормоза над служители чрез инспектората на министерството, защото това драстично намалява капацитета за продуктивна работа на министерството.

Въпреки абсурдната ситуация съм конструктивен и се надявам критиките и притесненията ми да бъдат възприети именно така. Без промяна в подхода няма да бъдат постигнати целите, които всички сме си поставили за по-ефективен и прозрачен публичен сектор.

Материалът Рискове и притеснения, свързани с Министерството на електронното управление и електронната идентификация е публикуван за пръв път на БЛОГодаря.

По покана на Европейската Комисия участвах на конференция за използването на софтуер с отворен код в обществения сектор, на която споделих следното:

България през 2016 г. прие закон, с който всички административни органи се задължават при възлагане на разработка на софтуер, в договорите и спецификациите си да включат клаузи, с които да изискват разработеният софтуер да е публичен (от първия ден на разработка) и да е с лиценз, който позволява безплатно използване от всеки.

Това е важна мярка, за чието спазване настоявам във всичките си качества оттогава, по следните причини:

1. Преизползване – когато кодът на една система е публичен, всеки друг, разработващ сходна функционалност, може да го използва и развива. В системите в публичния сектор има много повтарящи се изисквания и е загуба на време и пари да се разработват всеки път от нулата.
2. Прозрачност и доверие – след като системата е разработена с публични средства, на обществото се дължи кода на системата. Така ще знаем как точно работи дадена система (и че работи правилно, съгласно закона, а не съгласно нечии интерпретации, както се оказа наскоро със системата за мониторинг на наличностите на лекарствата), и ще имаме повече доверие в нея (неслучайно направих предложение да се изгради нов софтуер на машините за гласуване, който да бъде отворен, но за съжаление това предложение не се прие в миналия парламент)
3. Качество – когато изпълнител на дадена поръчка знае, че кодът, който произведе, ще бъде публичен, внимава повече да спазва добрите практки, да прави кода по-четим и по-подреден. Не един път съм чувал, че „ще го публикуваме, ама чакай първо да го пооправим малко“. Включително на самата конференция, от колега от друга държава.
4. Одитируемост – държавата трябва да може да одитира какво точно е получила и да гарантира, че е получила (и че в продукционна среда работи) правилният софтуер. Примерът с тол системата, чийто изходен код липсва, показва защо това е важно – АПИ в момента не може да одитира в дълбочина собствената си система.
5. Ценова ефективност – има два аспекта на отворения код, свързан с цената за държавата, и по-точно за общата цена на притежаване (total cost of ownership). Първият е, че когато използваш готов продукт с отворен код, той е безплатен (спрямо цената на лицензите или абонамента за платен такъв). Но вторият аспект е, че когато нямаш кода да даден софтуер, или нямаш права да го модифицираш, си до голяма степен заключен за един доставчик. Ако лицензът на кода позволява модификации (каквото позволят всички open source лицензи), софтуерната компания, която го поддържа, може да бъде сменена, което пък означава конкуренция и съответно – по-ниска цена.

Имаме закона, имаме съответната наредба и шаблона за технически задания, имаме и правомощията за контрол по прилагането и съгласуване на заданията, така всички нормативни и процесни предпоставки са налице. Не е налице още културата и пълното разбиране у възллжителите защо това е важно (пример за това е моят въпрос до МВР защо по проекта за електронна идентификация все още няма публикуван изходен код, въпреки че се работи по него). Тук е моментът да отбележа, че мобилното приложение за електронна идентификация, която аз възложих като министър, също няма публикувана работната версия на код, защото проектът беше спрян в служебния кабинет и ключови негови части блокирани заради отказ от предоставяне на достъп до данни от МВР. Ако проектът беше продължил, щях да настоявам за работа именно в хранилището на МЕУ.

Освен честото неспазване на изискванията, имаме и притеснения от страна на службите за сигурност, които виждат риск в разкриването на изходния код. Аз не съм съгласен с тези притеснения, тъй като не се публикува нищо, свързани с оперирането на системата в продукционна среда – нито криптографски ключове, нито пароли, нито мрежови настройки. Да, съществува риск от наличие на уязвимости в кода, които да бъдат видени от хакери, но криенето на кода не означава, че уязвимостите не са там. Криенето, обаче, може да попречи на „белите хакери“ да ги докладват преди да бъде злоупотребено с тях.

Невинаги е възможно да се възлага разработка на софтуер с отворен код – понякога се придобива нещо готово, за което се купува лиценз или абонамент. Трябва предварително да е ясно на възложителя какво си поръчва – готов софтуер, разработка „на чисто“, или хибрид (готов софтуер с надграждане със специфични модули). Именно последното е случаят с тол системата, но държавата не е знаела какво поръчва, и вместо да получи кода на доработените за нея функционалности, е получила само лиценз.

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

Има и случаи, в които изпълнителят твърди (с право или не), че определени библиотеки, съдържащи основни функционалности, са си негови и той само дава лиценз за тях. Това е възможно, като в такива случаи (какъвто би следвало да бъде и този с тол системата), държавата може да поиска една от две опции. За предпочитане е т.нар. code available, вкл. с право на модификации. Т.е. кодът не се публикува, изпълнителят запазва авторските си права, но предоставя кода на възложителя, както и правото той да възложи надграждане на друг. Това е сложно за уреждане, и включва риск от „падане на гаранция“ („не знам какво сте му правили, при нас си работи“). Втората опция е т.нар. source code escrow – кодът се депозира в трета страна, която го предоставя на държавата в случай, че производителят фалира или спре работата по продукта. Това е по-малко желателният подход, тъй като обвързва държавата с един доставчик, но поне „фаталните“ сценарии са покрити.

Остава и казусът с т.нар. „софтуер като услуга“ (SaaS). Там държавата може да поиска достъп до кода, за да го одитира, но нито може да го публикува, нито да го надгражда (освен ако самата система няма plug-in архитектура). Много съвременни софтуерни компании предпочитат „софтуер като услуга“, защото това им дава повторяем приход, по-лесно управление на клиентите и по-добра видимост върху използването. Само че SaaS е оперативен разход, а не капиталов. SaaS представлява задължително заключване за един доставик. Ползите са удобството и нулевата инвестиция в хардуерна инфраструктура. В някои случаи SaaS е валиден подход, но според мен софтуерните компании могат да предоставят т.нар. self-hosted версии на своите продукти, което би било от полза за обществени организации.

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

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

Закупуването на софтуер, неговото управление и поддръжка, изчисляването на цената на собственост и всички останали аспекти са сложни. В един блогпост или няколко изказвания на конференция не могат да покрият всички тези сложности. За да не допуска държавата грешки, трябва да има достатъчно познание по тези въпроси в нейните структури. Министерство на електронното управление и структурите към него могат да бъдат център за такова познание, но не следва да са единствените. Затова обмисляме предлагането на фигурата на Chief information officer (CIO) за администрациите, които да са не просто ИТ директори, отговарящи за оперативните ИТ задачи, а които да имат директна комуникация с органа на власт и да изграждат стратегията и да водят дигиталната трансформация на администрацията.

С времето ще се формират добрите практики, ще се натрупа опит и няма да се допускат грешки, които струват на държавата скъпо, и от които понякога губим години в дадена сфера. А отвореният код ще бъде важен инструмент за дигиталната трансформация.

Материалът Отворен код и придобиване на софтуер от държавата е публикуван за пръв път на БЛОГодаря.

Днес участвах на срещата на премиера Денков, МЗ, МЕУ и Информационно обслужване със съсловните организации в сектор „здравеопазване“ на тема „електронна рецепта“.

Предложението на МЗ задължението за изцяло електронни рецепти да се премести за април има своите рискове, но дава възможност за повишаване на доверието в системата.

Аз предложих пет неща на срещата:

1. Мека прогенерична политика чрез промяна на опциите по подразбиране – чрез софтуерите, по подразбиране да се позволява генерично заместване, а ако лекарят смята, че трябва да се отпусне лекарство от конкретен производител (има легитимни причини за това), да трябва да отбележи „забранявам заместване“. По този начин фармацевтите ще могат да отпускат еквивалентни лекарства в повечето случаи, ако няма от предписаното – това беше един от основните проблеми при старта на е-рецептите. С това предложение се оставя решението у лекаря.

2. Ясно дефиниране на изключенията, при които могат да се ползват хартиени рецепти – домашни посещения, лекари, които не могат използват технологии, чуждестранни лекар. Също: срив в системата. Това го предложих миналата година на служебния кабинет, когато отмениха електронната рецепта, но се го възприеха.

3. Въвеждане на стандарт за удобство/потребителско изживяване/UX на софтуерите, с които се изписват рецептите. Според мен немалка част от недоволството в лекарското съсловие е поради по-бавното и по-неудобно изписване чрез софтуер. В стандарта може да се включат конкретни тестове и засичане на време за изписване.

4. В „гратисния период“ да се отстранят всички оставащи технически проблеми, с много оперативен процес между МЗ и Информационно обслужване, като големите болници и ДКЦ-тата да се включат активно в тестовете.

5. При отпускане на лекарства по хартиени рецепти (след април) да има улеснено въвеждане на данните от фармацевтите, напр. автоматично при верификация на лекарството.

Тези предложения могат да бъдат включени в Наредба 4, за да бъдат реализирани до април.

Електронните рецепти намаляват порочните практики в системата. Дават повече видимост и възможност за провеждане на здравни политики. Помагат с преодоляването на проблема с антибиотичната резистентност. Затова тези усилия на всички страни си струват.

Материалът Предложения за електронните рецепти е публикуван за пръв път на БЛОГодаря.

Малко понятия за анализаторите, които днес ще коментират темата:

• хеш / хеш код / чексума / криптографски идентификатор – това е сравнително кратък низ от символи, който представлява уникален отпечатък на даден софтуер или файл. Той е видим за всички, по закон е публичен и се публикува на сайта на ЦИК . И трябва да е еднакъв за всички машини.
• изходен код – това е серия от инструкции, които описват поведението на софтуера. Той е доста редове (вероятно над половин милион за софтуера на машините). Той се представя в цялост на партиите и коалициите по закон, т.е. всички сме го виждали официално, пред представители на ДАНС.
• парола – паролата всички знаят какво представлява. В този процес тя се ползва само за допълнителна защита на ключа (и са три пароли, на трима членове на ЦИК). Писането на пароли не се вижда на екран – дори звездички не се виждат.
• ключ / криптографски ключ / частен ключ – това е последователност от символи (реално – байтове), чрез която се подписва софтуера на машините. Машините зареждат само софтуер, подписан с ключа на ЦИК. В процеса по изграждане ключът не се визуализира на екран. Записва се на диска, защитен с комбинация от три пароли. При ново изграждане се генерира различен ключ всеки път, на случарн принцип, като той не дава достъп до машините. Възможност (индиректна) да се инсталира софтуер на машините дава ключът на ЦИК за тези избори и ключът от предните избори (заради процес, който е извън обхвата на обяснението на понятията).

Накратко – всичко, което е видимо на екран, е публично или частично публично (за регистрираните партии) по закон. Всичко, което трябва да е тайно – ключът+паролите, не се показва на екран, а повторно генериране не дава достъп до машините.

Тези разяснения вероятно са излишни, защото въпросът беше превърнат в политически. Но тъй като днес е ден за размисъл и по студията няма да има политици, се надявам анализаторите да са по-прецизни.

Материалът Хеш, код, ключ – обяснение на понятия е публикуван за пръв път на БЛОГодаря.

Вероятно в опит да оправдаят слаб изборен резултат в София и други големи градове, партиите извън ПП и ДБ се надпреварват да обясняват за конспиративни теории за машините, защото зам-министър бил снимал екран на лаптоп. Нека да направя няколко важни разяснения, за да не се вихрят колегите с гръмки, но безсмислени словосъчетания с „кодове“ и „флашки“.

1. Няма как снимки или видео да компрометират машините. Изходният код е вероятно над половин милион реда – всеки, който някога е виждал код, знае, че това са пълни глупости. Tака или иначе машините са само принтери, които разпечатват разписки, а резултатът се брои от секционните комисии.

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

3. Единственото тайно нещо в процеса, от което зависи сигурността, са паролите на членовете на ЦИК и ключа, който е случайно генериран и защитен с тези пароли. Ключът се съхранява в ЦИК, а МЕУ няма достъп нито до него, нито до паролите, които бяха написани от членовете на ЦИК в процеса на т.нар. „доверено изграждане“

4. Екипите в Министерство на електронното управление трябва да документират процеса по преглед, изграждане, тестване, провизиране и т.н. Моето допускане е, че като част от този процес са правени снимки и записи от отговорните за процеса. Заместник-министърът е бил натоварен да контролира и координира дейностите по Изборния кодекс.

5. Да твърдиш, че снимка или запис на екран компрометира изборите е все едно да твърдиш, че чистачката, която пуска прахосмукачка в близост до касата на ЦИК, може да компрометира изборите. С една дума – нелепо.

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

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

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

Материалът Фалшивият скандал с машините е публикуван за пръв път на БЛОГодаря.

Да коментирам и другата тема, свързана с е-здравеопазване – електронните извинителни бележки. Те са добра и правилна стъпка, но също като рецептите, показват слабости на процеса.

Оплаквания от електронните бележки има доста, част от тях са неоснователни, но част от тях са валидни. Неоснователни са твърденията, че само лични лекари или само лекари с договор с НЗОК могат да издават такива. Това не е вярно – всеки лекар трябва да вкарва данни в НЗИС (централната система за е-здравеопазване). И като параметър на всеки преглед може да бъде посочено и извиняване на отсъствия.

Проблемът е в това, че лекарите стават „нотариуси на сополите“, защото трябва в електронната система да обвържат извинението на отсъствия с проведен преглед. Това задължение не е ново. Просто сега, с електронната система, не може да се заобиколи, което повдига въпроса за неговата адекватност.

Дали с раздаване на кочани, дали със съобщения по вайбър и минаване „само да взема една бележка“, лекари и родители са намерили практично заобикаляне на писаните правила, с което са облекчавали здравната система.

Нашата работа като законодател, и като управляващи, е да направим писаните правила адекватни на реалността. Има два подхода, които се допълват.

Първият в регламентирането на телемедицината. Не точно „преглед по Вайбър“, защото трябва да са налице редица гаранции, но близо до това. Внесли сме вече такъв законопроект. Така няма да трябва да се събират излишни опашки пред кабинетите.

Вторият подход е правото на родител да извини няколко дни отсъствия по своя преценка, в допълнение на сегашните „по семейни причини“. Това е практика по света. Да, родителите нямат медицинска експертиза, но няма нужда за всяко отсъствие да има диагноза с код по МКБ. Отсъствие за неразположение по преценка на родителя, с разумно ограничение, е напълно нормална житейка хипотеза. Аз напр. имах мигренни болки в училище. Нужна ли е бележка за главоболие? По-скоро не.

Това извинявяне също може и трябва да бъде електронно. Аз бих пакетирал това право с попълване на въпросник за симптомите, защото рискът при такъв подход е да бъде пуснато на училище привидно здраво, но заразно дете (ако има епидемия, напр.)

Представете си прикожението еЗдраве на МЗ, в което по ЕГН на дете и родител и попълване на въпросник, се предоставя възможност за извиняване на отсъствия. Пак проследимо, пак събираме информация, пак се ограничават злоупотреби (с ограничения броя дни), но без претоварване на здравната система.

Електронното извиняване на отсъствия е правилна стъпка, но може да се подобри, като го използваме за поправяне на проблемите на отдавна съществуващия и успешно заобикалян нормативноустановен ред.

Материалът Подобрения по електронните извинителни бележки е публикуван за пръв път на БЛОГодаря.

Електронната рецепта. Както често се случва, когато електронизираме един процес, излизат на повърхността неговите вградени дефицити, които са оставали невидими досега.

Когато лекар предпише антибиотик Аугментин на бяла рецепта, но такъв няма в аптеката, там те питат искаш ли еквивалентен на него (случвало ми се е – в три аптеки го нямаше, върнах се и взех генерик).

Именно тази особеност – че в електронната рецепта има маркер за позволяване или непозволяване на генеричното заместване, което фармацевтите не могат да не изпълнят, е причината за обикалянето на много аптеки и връщанията при лекаря. А С хартиената рецепта това, че някой не следва стриктно чл. 34 на съотверната наредба оставаше под радара.

Има, разбира се и други проблеми. Напр. има(ше) бъгове и „непочистени“ данни за лекарствени кодове. Тъй като цялата система разчита на екосистема от софтуер на частни доставчици (и само напоследък на едно държавно мобилно приложение за случаите, в които лекарят не може да е на компютър), е очаквано в първите дни на всяка промяна да има малки проблеми. Със сигурност можеше да има повече комуникация от институциите към заинтересованите страни – лекари, зъболекари, пациенти, фармацевти.

Има обаче и стандартното отлагане до последния момент, което се случи и с верификационната система преди години. Електронни рецепти има от доста време. Миналата година трябваше да влязат в сила за всички „бели рецепти“. Година по-късно, въвеждането на задължителна електронна бяла рецепта само за два вида лекарства не би трябвало да е изненада за никого.

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

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

Генерично изписване и заместване има почти навсякъде в Европа и е въпрос на политическо решение. То не е толкова просто, колкото изглежда, но ще трябва да го вземем скоро, защото иначе електронната рецепта ще бъде обвинявана от пациентите в грехове, които не са нейни. А ползите от нея са огромни за здравната система.

Материалът За проблемите с електронните рецепти е публикуван за пръв път на БЛОГодаря.

Миналата седмица гласувахме на второ четене много промени в Закона за общетвените поръчки. Промените са значителни, по целия закон, но нека да откроя няколко важни промени, които бяха приети и които са по наше предложения:

• Публикуване на договорите, сключени без обществена поръчка (над 50 хил лв.). Има редица изключения, при които не се правят обществени поръчки и досега оставаха скрити. Освен договорите, ще трябва да се публикуват и анексите към тях, както и приложенията, тъй като през анекси и приложения понякога се крият важни детайли по сключени догвоори. Останалите (под 50 хил., което е разумен праг) плащания ще се публикуват така или иначе с данните от СЕБРА. Тук не е важна просто сумата, а условията, по които е платена.
• Публикуване на договорите за телевизионно време над 10 хил. лв и пълна разбивка на разплатените средства по доставчици на медийни услуги при такива договори и при поръчки с агенции-посредници, които разпределят парите към множество медиии. С това ограничаваме възможността на властта (която и да е тя) скрито да насочва пари към медии и така покриваме критика в доклада на Европейската комисия за върховенството на закона във връзка със свободата на медиите.
• Данни за поръчките ще се събират в структуриран вид – стойност при сключване, стойност при изменение, единични цени на стоки и услуги, ценовите предложения, процент участие на фирми в консорциуми, стойности на договори с подизпълнители, брой подадени оферти и др. След като се съберат, данните се публикуват като отворени данни по международен стандарт. Това ще позволи много по-детайлен анализ на обществените поръчки от активисти, журналисти, анализатори. Промяната влиза в сила след 1г, в която да бъде надградена системата за електронни обществени поръчки
• Веднъж годишно действителните собственици и членовете на управителните органи на дружеств, които са получавали над половин милион лева, ще бъдат проверявани за принадлежност към Държавна сигурност от Комисията по досиетата.

Продължаваме систематично да правим държавата по-прозрачна и по-ефективна.

Материалът Изменения в Закона за обществените поръчки е публикуван за пръв път на БЛОГодаря.