Портал для пацієнтів

Чотири «демони» Проєкту Концепції розвитку eHealth: Частина 1. Критична точка «Архітектура ЕСОЗ або eHealth»

Чотири «демони» Проєкту Концепції розвитку eHealth: Частина 1. Критична точка «Архітектура ЕСОЗ або eHealth»
Частина 28 із 31 спецтеми
Розгорнути перелік тем

«Опиратися можна тільки на те, що має супротив»


СЕРІЯ ПУБЛІКАЦІЙ: "Чотири «демони» Проєкту Концепції розвитку eHealth"
 Частина 1. Преамбула. Критична точка «Архітектура ЕСОЗ або eHealth» (поточна)
- Частина 2. Критична точка «Організаційно-управлінська модель eHealth»
Частина 3. Критична точка «Монетизація ЕСОЗ»
Частина 4. Критична точка «Державний кабінет пацієнта»
Завантажити весь матеріал одним файлом у форматі PDF


Друге засідання робочої групи з розробки Концепції розвитку електронної охорони здоров'я (14.09.20)

Формат та терміни робочої групи (далі РГ), навіть при бажанні її ініціаторів сформувати якісний документ, мають всі шанси не дозволити цього зробити, а критичні зауваження можуть бути не почутими та ризикують не бути врахованими.

Складається відчуття, що поточна ситуація з розвитком ЕСОЗ влаштовує більшість її творців, що і закладається в Концепції та підлягає закріпленню в стислі терміни. У мене немає бажання навмисно, з якоюсь корисною особистою метою безпідставно уповільнювати цей про.цес.

Але залишається все менше можливості та мотивації брати участь у засіданнях РГ та ретельно працювати над документом з огляду на кількість необхідних змін, на мою думку, обраного способу їх подання та на реальну оцінку своїх можливостей вплинути на кінцевий результат, який влаштовує більшість зацікавлених сторін.

Звичайно, з огляду на деякі надані критичні зауваження до Концепції від представників Світового банку, який є, безумовно, потужним учасником процесу, залишається надія, що частина з них буде врахована, не зважаючи на стислі терміни підготовки документу.

Оскільки я вже увійшов в робочу групу та витрачаю на це купу часу, я прагну зберегти свою позицію публічного висвітлення максимально незалежного та об’єктивного бачення процесів в сфері трансформації СОЗ, в тому числі в напрямку eHealth.

«Рукописи не горять» або навіщо викладати 15+ сторінок про eHealth, приймаючи участь в роботі робочої групі з розробки Концепції розвитку електронної охорони здоров’я?

Критичні точки Проекту Концепції розвитку eHealth

Як ви розумієте, чотири години засідання робочої групи з розробки Концепції електронної охорони здоров'я 14.09.20 та висловлювань думок, коментарів, заперечень та ремарок приблизно 15-ти активних на цьому засіданні членів РГ з розробки Концепції розвитку електронної охорони здоров’я – це чималий контент. Орієнтовно в засіданні брали участь 12-15 членів РГ онлайн і 15-20 офлайн.

Одразу зауважу, що я не брав раніше участі в подібних робочих групах, тому мої не досить оптимістичні загальні враження від процесу, ефективності та можливого впливу на кінцевий якісний результат важливого документу можуть бути частково суб’єктивними.

В процесі обговорення часто виглядало так, що члени групи, маючи вже сталі уявлення про положення, значення термінології, закладені в різні документи, розуміють кожен своє і говорять чи заперечують про те, що розуміють саме вони.

В такій ситуації можу лише поспівчувати тим, хто буде намагатися узгодити та фіналізувати ці речі в кінцевому варіанті документу.

Тепер по суті, але зауважу, що наводяться не всі аргументи чи обгрунтування, а лише часткові. Але об’єм опису навіть цих критичних точок дозволяє уявити складність та комплексність цього важливого документу.

► Завантажити Проект Концепції розвитку електронної охорони здоров’я (е-здоров’я, eHealth)

Важливо нагадати, що проєкт Концепції справедливо намагається розділити дві суті (терміни):

• ЕСОЗ – те, що вже реалізовано, що фактично закріплює в законодавчому-стратегічному полі реалізовані рішення, функції та підходи;
• eHealth – як середовище в цілому.

На друге засідання пропонувалося винести (надіслати) від всіх членів групи критичні зауваження (заперечення) щодо структури документу (яких розділів та положень не вистачає) та з якими учасники групи категорично не погоджуються.

Мої коментарі та пропозиції можете знайти за посиланням. Якщо вистачить духу, то буде краще зрозуміло про що мова піде далі, адже всі критичні зауваження, що були винесені на друге засідання там також є.

► Завантажити Поточні критичні зауваження та коментарі до Проекту Концепції розвитку електронної охорони здоров’я (Прилипко Є.В.)

На засідання робочої групи 14.09.20 були винесені ЧОТИРИ критичні питання:

1. Архітектура ЕСОЗ або eHealth
2. Організаційно-управлінська модель eHealth
3. Монетизація ЕСОЗ
4. Державний кабінет пацієнта

Одразу скажу, що 70% часу обговорення забрало на себе перше питання, тому і в цьому пості йому буде відведено більше. Обговорення затяглося з двох причин:
• Питання важливе, спірне та неоднозначне, що впливає на інші критичні точки в різній мірі;
• Члени групи вкладали в це поняття різний зміст і не в останню чергу тому, деякі зазначали, що це питання давно вирішене і обговорене в 2017 році – у нас двокомпонентна модель: центральна база даних та периферійний компонент (МІСи), що складає разом ЕСОЗ і цього достатньо.


Частина 1. Критична точка «Архітектура ЕСОЗ або eHealth»

Заперечення виглядали від членів групи по різному:

«..., чи це буде єдина система національного рівня, чи централізована система, яка все ж буде мати регіональні підсистеми»
«Прописати архітектурні принципи побудови ЕСОЗ: існує центральний і периферійний компоненти»
«Необхідно доповнити концепцію положеннями про зберігання даних в МІСах, визначити яку саме інформацію можна зберігати та за яких умов.»
«Будь-які згадки про регіональні системи та децентралізацію необхідно прибрати, оскільки центральний компонент є єдиним, з єдиними стандартами та принципами зберігання та управління інформацією, зокрема для забезпечення цілей інтероперабельності»
«Не згоден з архітектурою повністю централізованого збереження всіх персоніфікованих медичних даних, що приводить до єдиної точки відмови системи та не забезпечує управління власними медичними даними виключно зі сторони самого жителя України»
«Проєкт Концепції змінює наявні наразі підходи стосовно централізованого зберігання даних в ЦБД. Тобто наразі є ЦБД, в якій мають зберігатись всі персональні дані, зібрані в рамках ЕСОЗ. Проєктом передбачено, що будуть дані, які не будуть передаватись до ЦБД і будуть зберігатись в спеціалізованих ІТС, проте не зрозуміло яких саме і які дані.»
«Не згоден з архітектурою ЦК - МІС. Це не повноцінно з точки зору світової практики, не дає можливості гармонічно, оперативно, паралельно, розвантажуючи бюджет, розвиватись регіонам, що є неприпустимо, недемократично і являє собою потенціально корупційну, небезпечну монополію всіх медичних даних країни в одних руках»

З іншого боку - про яку архітектуру ми говоримо? Архітектуру ЕСОЗ чи eHealth? На початку документу наведені ці два терміни і вони між собою не узгоджені.

Є така поговірка, якщо сперечаються розумні люди, то вони сперечаються за термінологію. Однозначної термінології на даний момент не напрацьовано. Ця неконкретність приводить до таких роздумів, висловлювань та заперечень.

Варто було б спочатку узгодити термінологію, намалювати схему термінології eHealth, як було зроблено до Концепції, яку запропонувала міжнародна компанія SMIS International, що і була за контактом, свого часу, найнята МОЗ України в рамках спільно с Світовим банком проекту у т.ч. для розробки Концепції eHealth.

Візуалізації термінології в концепції SMIS International надає чітке розуміння взаємного розміщення ЕСОЗ і Е-Здоров’я.

Якщо ЕСОЗ на даний час це переважно «білінгова» система для обліку та оплати за медичні послуги за програмою медичних гарантій, з архітектурою (логікою), яку «тягнуть» з Prozorro та якою зараз володіє, розвиває, формує пріоритети запровадження функціоналу, складає дорожню карту НСЗУ – то, можливо нехай вона залишається централізованим інструментом «білінгу» НСЗУ. В такому випадку, згідно існуючого законодавства та прийнятої термінології (у т.ч. визначення ЕСОЗ) кардинально і змінювати нічого не потрібно в нормативному полі.

А паралельно повинна почати свій розвиток повноцінна система eHealth, по тим принципам, які прийняли в цивілізованому світі. Поступово, шляхом узгодження та гармонізації, eHealth «накриє» або «поглине» ЕСОЗ, тобто ЕСОЗ стане частиною середовища eHealth. Це логічний вихід, який би всіх задовольнив, і учасників процесу створення національного середовища eHealth, користувачів та донорів. От тільки монополію вже буде складно створювати далі.

Якщо ж і надалі під ЕСОЗ будуть «заганяти» всі пріоритети, сервіси, реєстри, медичний функціонал, то підхід вже інший та інший результат.

Мабуть, ширше ніж я описав в своєму коментарі до першочергового тексту Концепції (за посиланням вище), чому я наполягаю на НАДАННЯ МОЖЛИВОСТІ зберігати та обробляти дані відповідно до затверджених (гармонізованих) стандартів, які передаються в ЦБД і зберігаються на рівні регіональному (на рівні регіону, мережі лікарень, об’єднання даних з декількох МІС у т.ч. на рівні потужного великого закладу), я зробити не зможу, але в доповнення до тексту додам лише один контекст, виходячи з декларованого пріоритету реформи фінансування системи охорони здоров’я.

В умова трансформації лікарняних мереж потрібні розробки майстер-планів розвитку госпітальних округів, стратегічних планів лікарень, визначення місця лікарні, її функцій в мережі, реального навантаження, порівняльний аналіз ефективності, оцінка фінансових ризиків та саме головне, з чого починається аналіз, – оцінка потреб жителів регіону, аналіз структури захворюваності та госпіталізацій в розрізі клінічних груп по лікарнях та відділеннях, існуючих маршрутів пацієнтів та демографії регіону.
Для аналізу діяльності лікарень регіону (госпітального округу) в порівнянні між собою потрібні дані про середню тривалість перебування у стаціонарі, частки хірургічних випадків та екстрених випадків, захворюваності, що підлягають амбулаторному лікуванню (не стаціонарного), структуру вторинних діагнозів, частки неуточнених діагнозів, складності пролікованих випадків по кожному відділенню, лікарні та й лікарю, і т.п. І це перелік без аналізу економічних даних діяльності лікарень.

Все це потрібно не зараз, а вже на вчора. Для того потрібні реальні, релевантні та актуальні дані та ІНСТРУМЕНТИ (не вибіркові дашборди), підкреслюю, програмні рішення (Інформаційні системи управління охороною здоров’я) - на рівні регіону (та вже б мали бути на рівні ЦК з різними рівнями доступу, але немає) для оцінки та побудови, планування ефективної регіональної мережі, забезпечення керівників всіх рівнів актуальними даними для прийняття зважених управлінських рішень.

Кожне хибне управлінське рішення, хаотичні панічні дії без ретельного прорахунку на основі даних – це зламані долі та зневіра у реформі медичних працівників та їх сімей, це зниження доступності, якості медичних послуг для пацієнта, звільнення медичних працівників, скорочення мережі надання медичних послуг тощо

В робочій групі немає жодного головного лікаря, економіста, статистика, власника медичного закладу, чи управлінця галузі ОЗ регіону, чи представника госпітальної ради і це враховуючи те, шо пріоритетом зараз є реформа моделі фінансування системи охорони здоров’я, що і зазначено у Концепції.

Більшість (програмісти, розробники) дивляться на ЕСОЗ та на eHealth, як на програмний код, «красивий стандарт, яким вони захоплюються», але потрібно дивитися більш широко та оцінювати поточні, реальні потреби учасників та головних споживачів переваг від впровадження eHealth, саме на поточний час, на зараз, і задовольняти ці потреби.

Це все стосується зараз, у тому числі, чутливої актуальної теми управління в умовах змін, економіки міжмуніципального співробітництва, зміни адміністративно-територіального устрою (зміни власника, перехід районних лікарень у власність та утримання декількох ОТГ і т.п.).

Я провів сотні, підкреслюю, сотні годин, як автор, ведучій та модератор в тісному спілкування та навчанні керівників, економістів, статистиків медзакладів. І це наживо, я вже не рахую онлайн-комунікації.

Чому я цим переймаюся? Ми можемо скільки завгодно говорити про доступність та якість медичної допомоги, як і самі медичні дані та їх безпеку, але це все не можливо без існування самих медзакладів і медичних працівників та їх доступності, не можливе ефективне оснащення медзакладів через розрахунок навантаження та реальну оцінку потреб населення в медичних послугах і т.п.

І через два-три роки (хто як рахує хоче) розвитку eHealth (яке потім стало ЕСОЗ) де все це в нашій гармонічні системі eHealth? Якщо декларований гармонічний, демократичний, конкурентний вільний ринок розвитку програмних рішень, що сприяє підвищенню їх якості – де ці рішення? Якщо дані є на рівні регіону в різних МІС та тепер вже мільйони записів в центральному компоненті, чому немає інструментів, так потрібних на різних рівнях управління СОЗ? Тому що власник ЕСОЗ, яким є НСЗУ, має абсолютно зрозумілі інші пріоритети та інтереси. Але від цього не повинні страждати пацієнти, лікарі, керівники всіх рівнів та нести збитки мережа надання медичних послуг в цілому.

Я на практиці можу сказати, що процес розробки майстер-планів чи стратегічних планів розвитку лікарень, як частини інтегрованої регіональної мережі, починається з складного та тривалого збору даних з різних джерел та різними способами у т.ч. через той же центр статистики, на який багато хто нарікає.

Щоб було більш зрозуміло, що саме мало б ВЖЕ бути у нас, як пріоритет в умовах болючих процесів зміни моделі фінансування та взагалі реформи СОЗ подивіться ось це відео «Потоки даних для прийняття управлінських рішень: Ситуаційний центр»

Моя думка така, що нехай собі ЦК розвивається з тими темпами та пріоритетами, які може та здатний собі дозволити. Головне по одним правилам та стандартам, не стримуючи розвиток регіональних систем (мереж). Це стане лише на користь потребам регіональних мереж закладів охорони здоров’я та, що важливо, пацієнтів, яких вони обслуговують.

А коли ЦК готовий буде приймати дані, поступово розширюючи, чи визначаючись, які з них йому потрібні в режими реального часу чи періодично (асинхронно) – вони «піднімаються» із закладів, чи регіональних мереж. Потрібно просто надати таку можливість розвиватися настільки ефективно (об’єднуючись по будь-якому зручному принципу) - наскільки вони хочуть, здатні та є ресурси.

Таким чином в архітектурі та Концепції закладається стримування гармонійного, швидкого розвитку екосистеми eHealth через обмеження розвитку регіональних eHealth середовищ.

Умовно кажучи, розвиток ЦБД і програмного забезпечення центрального компоненту, його пропускна здатність, функціонал, можливість збирати та обробляти дані, пріоритети в розробці, політична доцільність та популізм, проблеми з фінансуванням, з рештою, фахова та професійна здатність розробників впродовж наступних 5-10 років –

все це буде «вузьким» місцем, що буде стримувати розвиток eHealth та використання сучасних технологій та програмних рішень в регіонах для підвищення ефективності та якості надання медичної допомоги.

Базові принципи побудови електронної системи охорони здоров'я щодо її архітектури були окреслені в пропозиції Концепції від міжнародної компанії SMIS International, що і була за контактом свого часу найнята МОЗ України за контрактом в рамках спільно с Світовим банком у т.ч. для розробки Концепції eHealth. До речі, з якихось причин, представники цієї компанії не увійшли в робочу групу.

З тексту Концепції від SMIS International:

●Модель розвитку Е-ОЗ повинна забезпечувати запровадження як централізованих так і децентралізованих сервісів та послуг;
●Сервіс орієнтована архітектура (SOA) для забезпечення побудови розподілених систем;
●Гібридна архітектура, що дозволить гнучко реагувати на зміни потреб в процесі розвитку системи (підтримка модульності та гнучкості, забезпечення масштабування системи, поєднання централізованих та децентралізованих сервісів); Для пом'якшення ризиків, пов'язаних з єдиною точкою відмови, пропонується, що ЕМК буде розташовуватися в ДП ЕЗ та, при потребі, в обласних/регіональних центрах Е-ОЗ. Ця архітектура дозволить зберігати дані пацієнта в одній центральній базі даних ЕМК в ДП ЕЗ, а також в базі даних ЕМК області / регіону;
●Гібридна модель зберігання даних, де центральне сховище містить основне ядро даних про пацієнта, а додаткові дані, при потребі, отримуються з інших систем;
●На кожному рівні керування системою ОЗ повинна знаходитись тільки та інформація, що потрібна для прийняття рішення на відповідному рівні.

Я декларую демократичну модель вільного розвитку та конкуренції, програмних рішень, сервісів без виключної монополізації та централізації невизначеної кількості даних, набір яких може розширюватись, а доступ до яких обмежуватись через різні важелі та обставини у т.ч. через намагання запровадити монетизацію доступу до даних за рахунок тих, хто ці дані і вносить (про це окремо в критичній точці – монетизація).

Основним запереченням мого прагнення НАДАННЯ МОЖЛИВОСТІ, яке підтримує ряд інших членів групи є:

• Основні дані не можуть зберігатися в декількох місцях, оскільки це «копії» даних, вони будуть не релевантні, це декілька реєстрів.

Як на мене, це той випадок непорозуміння щодо принципів розподіленого збереження даних, що це не «копії», а доступ до одних і тих даних, що у т.ч. знімає питання існування «єдиної точки відмови» у вигляді необхідності прямого доступу до ЦБД в режимі реального часу;

• Неможливо проконтролювати безпеку збереження даних в регіонах чи, тим більше, на рівні кожного медичного закладу.

Але збереження даних в одному місті збільшує їх цінність, а значить зацікавленість «несанкційованого» відбору даних у т.ч. шляхом прямого підкупу відповідальних осіб (особливо в нашій країні) чи загрози залучення до зламу системи потужних груп кібер-хакерів, що у країні, в якій відбуваються складані внутрішньополітичні процеси та зовнішня агресія є дуже ймовірним.

• В регіонах недостатньо коштів на організацію та підтримку процесу безпечного збереження даних.

Тут я би не говорив за регіони, оскільки ми «надаємо можливість», і такою можливістю навіть зараз, ще до початку новітньої історії скористалися в регіонах, областях та навіть районах, об’єднавши всі ланки надання медичної допомоги в єдину регіональну мережу, на користь і лікарям і пацієнтам.

Наскільки ці заперечення мають значення з огляду для НАДАННЯ МОЖЛИВОСТІ розподіленого збереження даних за встановленими стандартами і який саме підхід несе в собі більше користі, шкоди, ризиків – можете поміркувати самі.

Єдине, що варто додати, це те, що ми дійсно знаходимося в дуже складному процесі намагання об’єднати дані в єдину інформаційну медичну мережу, як і більшість країн Світу. І тут варто дуже уважно вивчати досвід інших країн, їх помилки та перемоги.

Наприклад:

«У Нідерландах немає централізованої бази даних записів пацієнтів з огляду на законодавство та вимоги до безпеки даних пацієнта. Є національна точка обміну (National Exchange Point – LSP). 
Дані там не зберігаються, а поширюються через неї між лікарями різних ланок. Вони можуть обмінюватися/передаватися між лікарнями, але не можуть бути збережені централізовано. Така є ситуація із забезпеченням безпеки даних пацієнтів в Нідерландах»
(Тайм-код в відео: 13хв.00 сек.)

Відео-презентація: Як побудована eHealth в Нідерландах?
СПІКЕР: Guido Danen (Гидо Данен), Programme Manager Task Force Health Care (TFHC)
ТЕМА: Електронна система охорони здоров'я в Нідерландах (eHealth in the Netherlands)
► Відео: https://youtu.be/4kY2BdLcNdU
► Завантажити презентацію (PDF): https://bit.ly/2Yzmaxt

Такою шиною обміну даних в Україні цілком може бути Національна системи електронної взаємодії «Трембіта».

Наданий час рішення централізованого збереження даних із забороною збереження цих наборів даних в інших місцях з метою в т.ч. забезпечення обміну медичними даними між учасниками периферійного компоненту (МІС, сервісами тощо) виглядає, НАЖАЛЬ, більш зрозуміло, зручно, підконтрольно, вже частково працює, є очевидним з точки зору подальшої реалізації в найближчий перспективі, хоч із тими ж самими ускладненнями для користувачів.

Мало хто з учасників процесу бажає ускладнювати своє життя аналізом майбутніх ризиків, та замислитись, що простота та зручність рішення для всіх творців ЕСОЗ зараз, закладає катастрофічні ризики на майбутнє для всього середовища eHealth. Але ж навряд хтось з конкретних осіб в цьому майбутньому буде нести за це відповідальність, адже їх може і не бути до того часу, в умовах такого заплутаного та складного процесу побудови eHealth в нашій країні та звичної для нас колективної безвідповідальності.

Слайд з презентації: «Методологічна база розробки концепції національного eHealth». Дяченко С.О., заступник директора ДЗ “Центр медичної статистики МОЗ України”

Обговорення цього питання загалом зайняло біля двох годин. Після перерви слово було надано Сергію Дяченко, заступнику директора ДЗ «Центр медичної статистики», який впродовж 15 хвилин пробував провести «лікбез» та вирівняти розуміння щодо методологічної бази розбудови середовища eHealth, архітектури, цілей (змісту) Концепції, що вона має містити та на які питання давати відповіді. Наведу тут лише два переліка з презентації Сергія Дяченка.

Завантажити презентацію Дяченко С.О., «Методологічна база розробки концепції національного eHealth» в форматі PDF

Основні вимоги до концепції:

1) Має бути написана простою та доступною мовою, зрозумілою, зокрема, не фахівцям в інформаційних технологіях
2) Концепція має донести до медичного персоналу, управлінців всіх рівнів та пацієнтів їх майбутні профіти від розбудови eHealth середовища в державі
3) Концепція має бути зрозумілою представникам всіх міністерств та відомств, які будуть її затверджувати на КМУ
4) Концепція має бути зрозумілою представникам міжнародних організацій та донорам та містити посилання на рекомендації ВООЗ, Світового банку, USAID
5) Концепція має враховувати основні стратегічні напрямки розвитку держави

Основні розділи концепції:

1) Короткий аналіз стану інформатизації галузі ОЗ, основні недоліки
2) Передумови розробки
3) Глосарій понять
4) Цілі та макро-завдання eHealth
5) Посилання на базові документи ВООЗ та інших міжнародних організацій
6) Загальний опис ідеології, принципів функціонування, архітектури та платформи eHealth
7) Визначення базових міжнародних інформаційних стандартів
8) Ролі учасників розбудови eHealth та їх очікуванні профіти
9) Загальний опис інформаційної безпеки персональних даних жителів та держави
10) Імплементація в міжнародну медичну інфраструктуру
11) Принцип масштабування та розвитку
12) Основні джерела фінансування розбудови eHeakth
13) Макро-план розбудови eHealth, як мінімум на 5-7 років
14) Чіткі KPI досягнення результатів на кожному етапі, зрозумілі донорам та інвесторам

Що цікаво та дещо характеризує демократичний склад робочої групи.

Реакція на цей виступ була в цілому позитивна, хоча і різна, від «хватить вже дискутувати, скільки можна треба, потрібно щось прийняти швидко», до «все вирішено і узгоджено з основними учасниками і концепт має бути прийнято».

Заступник міністра щиро та з повагою подякував за змістовну та цікаву доповідь Сергія Дяченко та зауважив, що саме тому, пан Сергій був залучений до роботи робочої групи, як експерт.

А директор Департаменту розвитку ЕСОЗ України НСЗУ зазначив, що члени робочої групи не потребують повчальних «лекцій».


ЧИТАТИ ДАЛІ: 
"
Чотири «демони» Проєкту Концепції розвитку eHealth"
• Частина 1. Преамбула. Критична точка «Архітектура ЕСОЗ або eHealth» (поточна)
- Частина 2. Критична точка «Організаційно-управлінська модель eHealth»
- Частина 3. Критична точка «Монетизація ЕСОЗ»
Частина 4. Критична точка «Державний кабінет пацієнта» (поточна)

Завантажити весь матеріал одним файлом у форматі PDF


З повагою та вірою у майбутнє,
Євген Прилипко,
Координатор та менеджер проектів у сфері управління та організації СОЗ, незалежний консультант з питань
eHealth та трансформації СОЗ

P.S.
Це пам'ятне фото 06.02.18 з урочистого дня передачі Проектним офісом системи eHealth Міністерству охорони здоров'я у стані MVP – minimum viable product (мінімально життєздатний продукт)

Цитати:
«Ми дуже чекаємо, коли eHealth запрацює не в тестовому режимі, а в роботі лікаря зможе бути менше паперів і більше пацієнта. Ми вдячні і багато навчилися у співпраці з вашою командою, і  ви створили дійсно унікальну річ», – доктор Уляна Супрун.
«...Ми з вами практично створили майбутнє вже сьогодні, але й те, яким воно буде, залежить від всіх нас. Відтепер завдання громадського сектору – контролювати, аби темп цієї реформи не знижувався, а розробка eHealth продовжувалась з дотриманням задекларованих принципів», - Ярослав Юрчишин, виконавчий директор Transparency International Ukraine.
 


Нема коментарів