Вчера ИТ компании обявиха, че ще подарят 15 000 часа труд на специалисти, за да се подобрят системите на здравеопазването у нас. Това стана ясно на брифинга в Министерски съвет с участието на правителството и представителите на "Асоциацията за иновации, бизнес услуги и технологии". Очакването е до края на 2021 г. да има електронно здравеопазване у нас.

OFFNews потърси мнението на софтуерни специалисти, които да разяснят предстоящите стъпки за създаване на софтуер за системата на здравеопазването и основните въпроси, които стоят пред реализацията на проекта.

Ето какво споделиха специалистите, пожелали анонимност:

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

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

Най-важните от тях могат да бъдат подредени в следния списък:

1. Необходимост от използване на нови операционни системи (например нова марка телефони, за които има търсене и трябва да се направи решение)

2. При използване на интернет за комуникация – необходимост от поддръжка на нов браузер за системата

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

4. Молба за клиентска промяна – клиента първо е казал, че иска едно нещо, след това като го види си променя мнението.

5. Незаобиколим софтуерен проблем ( бъг ), който се възпроизвежда трудно, но има силно влияние върху продукта (например рестартира важен сървър ).

6. Доказана уязвимост на част от използвания код, рапортувана в базата данни на световната агенция за сигурност ( NIST: National Institute of Standards and Technology ). Такъв пример имаше преди с OpenSSL например.

7. Промяна в законодателството, изискваща промяна в поведението на системата.

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

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

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

11. Запазване на копие ( backup ) на криптираната информация, а също и копие на ключовете, които ще бъдат ползвани за декриптирането ѝ.

12. Осигуряване на различни нива на достъп до наличната информация – като на всяко ниво на изискване на информация се определя какъв служител би могъл да има достъп.

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

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

15. Тъй като кризата е породена от миграция на хора, се очаква достъп до системата да имат митници, пропусквателни пунктове и пр.

Кое е притеснителното?

Всичко това води до мислите, че всъщност медийното послание от вчера беше как държавата ще разреши на кръг от ентусиасти да създаде продукт, а в действителност това добро желание ще доведе до "сватба" между държавата и определен кръг частни фирми, които ще създадат услуга.

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

Скептицизмът идва не заради професионална завист или недоверие към специалистите, които стояха до Премиера на пресконференцията, а заради обявените 15 хиляди часа. Това по груби сметки са 4-5 месеца труд на 20 човека. Изпълнението на такава задача с толкова хора за такова време ще доведе неминуемо до компромис с качеството. 

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

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

Докато този процес не стане прозрачен, ще има огромни съмнения в безкористността на помощта. Това, което не е изказано на глас е, че немалка част от ИТ бизнеса в момента влиза в криза и до 3-4 месеца ще има немалко хора, с които има подписани договори, но няма да има работа за тях.

Затова важните въпроси тук са следните:

1. Кой ще дефинира клиентските изисквания – или казано по-просто: знае ли в момента Министерство на здравеопазването от какво има нужда?

2. Ще има ли някакъв вид обществено обсъждане около тези изисквания?

3. Кой ще контролира качеството на работата?

4. Кой ще контролира сигурността на информацията получена през тази система?

5. Опция ли е подобен проект да бъде пуснат с отворен код по подобие на наличното в Естония решение за електронно правителство?

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

7. Кое министерство или агенция ще поддържа и ще носи отговорност хардуера, на който се изпълнява решението, за да се гарантира конфиденциалност? Ако планът е обявената компания „Информационно обслужване“ да бъде отговорна, то има ли достатъчно експерти със специфична подготовка за опазване на информацията? За пример в Чехия, Финландия, Холандия, Полша, Словакия, и Литва ( Ministry of Interior ) е взето решение подобен тип сървъри да се стопанисват от техния еквивалент на Министерство на вътрешните работи с аргументацията, че хората от тази система имат специална подготовка за работа с „вътрешна информация“.

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

Хубав въпрос би бил – не е ли редно, когато държавата предлага услугата – тя да може също така и да предоставя електронния ключ на собственика на данните?