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

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

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

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

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

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

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

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

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

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

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

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

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

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

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