Код ДК 021:2015: 85150000-5 – Послуги діагностичної візуалізації (Послуги з розшифрування, опису та інтерпретації даних досліджень мультизрізової комп’ютерної томографії із...

Текст рішення

РІШЕННЯ

№3184-р/пк-пз від 18.03.2026 Комісія Антимонопольного комітету України з розгляду скарг про порушення законодавства у сфері публічних закупівель (надалі – Комісія), розглянувши скаргу товариства з обмеженою відповідальністю "УКРАЇНСЬКИЙ ПІВНІЧНО-СХІДНИЙ ІНСТИТУТ ПРИКЛАДНОЇ ТА КЛІНІЧНОЇ МЕДИЦИНИ" (код ЄДРПОУ 31066166) від 07 березня 2026 № UA-2026-02-16-013296-a.b1 (надалі – Скарга) щодо порушення Замовником порядку проведення Процедури закупівлі,

ВСТАНОВИЛА:

Надалі за текстом вказаного рішення терміни та визначення:

- Закон України "Про публічні закупівлі" – Закон;

- Особливості здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України "Про публічні закупівлі", на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування, затверджені Постановою Кабінету Міністрів України від 12.10.2022 № 1178 "Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України "Про публічні закупівлі", на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування" – Особливості;

- тендерна документація – Документація;

- тендерна пропозиція – Пропозиція.

Скаржник повідомляє про порушення Замовником порядку проведення Процедури закупівлі та просить, зокрема, зобов'язати Замовника скасувати рішення про відхилення Пропозиції Скаржника.

Рішенням Комісії від 10.03.2026 № 2675 -р/пк-пз Скарга була прийнята до розгляду та зобов’язано Замовника надати пояснення по суті Скарги.

Замовником на веб-порталі Уповноваженого органу надано пояснення по суті Скарги.

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

Відповідно до інформації, розміщеної на веб-порталі Уповноваженого органу з питань закупівель, свої Пропозиції для участі у Процедурі закупівлі подали наступні учасники:

1) Скаржник 2) товариство з обмеженою відповідальністю "Радіоланс" (надалі - ТОВ "Радіоланс", Переможець) Відповідно до інформації, розміщеної на веб-порталі Уповноваженого органу, розкриття Пропозицій відбулось 25.02.2026.

Відповідно до інформації, розміщеної на веб-порталі Уповноваженого органу, Пропозиція Скаржника відхилено Замовником, Переможцем Процедури закупівлі визначено ТОВ "Радіоланс".

Інформація про відхилення Пропозиції Скаржника оприлюднена на веб-порталі Уповноваженого органу 02.03.2026.

Повідомлення про намір укласти договір з ТОВ "Радіоланс" оприлюднено на вебпорталі Уповноваженого органу 03.03.2026.

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

У зв'язку з наведеним були розглянуті підстави для відхилення Пропозиції Скаржника та встановлено наступне.

Відповідно до протоколу від 02.03.2026 № 35 підставою відхилення Пропозиції Скаржника було наступне:

"… Учасником ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "УКРАЇНСЬКИЙ ПІВНІЧНО-СХІДНИЙ ІНСТИТУТ ПРИКЛАДНОЇ ТА КЛІНІЧНОЇ МЕДИЦИНИ" у складі тендерної пропозиції надано інформацію та / або документи, які не відповідають умовам технічної специфікації та іншим вимогам щодо предмета закупівлі тендерної документації та не є невідповідностями у інформації та / або документах, що може бути усунена учасником процедури закупівлі відповідно до пункту 43 Особливостей, а саме:

Учасником не було підтверджено вимогу до інформаційної взаємодії онлайн платформи з Медичною інформаційною системою Замовника, а саме:

Автоматична передача даних пацієнта з Медичної інформаційної системи (МІС) Замовника до ОП (в складі тендерної пропозиції надати копії (скріншоти) екранних форм/відео-презентації, що демонструють функціональність)-відсутня інформація;

Формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника (в складі тендерної пропозиції надати копії (скріншоти) екранних форм/відеопрезентації, що демонструють функціональність) -відсутня інформація;

Можливість контролю виконання стану заявки в МІС Замовника-відсутня інформація;

Автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовникавідсутня інформація.

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

Керуючись абзацом 2 підпункту 2 пункту 44 Особливостей замовник відхиляє тендерну пропозицію ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "УКРАЇНСЬКИЙ ПІВНІЧНО-СХІДНИЙ ІНСТИТУТ ПРИКЛАДНОЇ ТА КЛІНІЧНОЇ

МЕДИЦИНИ".

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

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

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

Вимоги пункту 5.1 технічної специфікації щодо наявності інтерфейсів "Керівника", "Лікаря" та "Користувача" фактично підтверджені поданими інструкціями.

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

Інструкція по роботі з Dicom-платформою для ролі "Лікар Замовника" безпосередньо підтверджує наявність функціоналу користувача Замовника щодо створення заявки.

У документі зазначено, що користувач переходить до розділу "Заявки на діагностику", обирає опцію "Нова заявка" та заповнює необхідні поля заявки.

У наступних сторінках показано, що в заявці обирається лікар, пацієнт, дата обстеження, номер обстеження, зона обстеження та інші обов’язкові реквізити, після заповнення яких кнопка "Створити заявку" стає активною.

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

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

Як зазначає Скаржник, це свідчить, що платформа працює з карткою пацієнта, даними пацієнта та прив’язує їх до конкретної заявки.

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

Додатково інструкція для ролі "Лікар Замовника" підтверджує можливість завантаження матеріалів дослідження у форматі DICOM. У ній зазначено, що архів досліджень формується з файлів з розширенням .dcm, далі користувач переходить до вкладки "Файли", натискає "додати", обирає тип Dicom та вказує назву. Окремо вказано, що у "Журналі подій" відображається успішне відправлення файлів досліджень до PACS та успішне завантаження архіву файлів до платформи. Це прямо спростовує припущення про відсутність підтвердженого функціоналу електронного обміну матеріалами заявки.

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

Інструкція по роботі з Dicom-платформою для ролі "Лікар Виконавця" додатково підтверджує, що створена Замовником заявка проходить подальший електронний цикл опрацювання в системі. У ній прямо зазначено, що лікар виконавця обирає лікаря, завантажує перелік заявок через кнопку "Пошук", обирає конкретну заявку та призначає її, після чого бере заявку в роботу. Надалі система дозволяє переглядати вкладки "Дані заявки", "Файли" та "PACS", тобто фактично працювати з тим самим електронним об’єктом заявки, який був сформований Замовником. Це свідчить, що платформа забезпечує безперервний маршрут заявки від моменту її створення Замовником до моменту її опрацювання Виконавцем.

Та ж інструкція для ролі "Лікар Виконавця" підтверджує один із ключових елементів технічної специфікації, а саме можливість опису дослідження в системі та створення висновку з накладенням підпису. У документі прямо зазначено, що висновок створюється у відповідному розділі шляхом завантаження готового висновку у форматі .pdf або шляхом створення його за шаблоном у програмі, після чого користувач натискає кнопку "Підписати", може переглянути документ у форматі .pdf або змінити його. Далі вказано, що після підписання висновку робота із заявкою завершується, вона надсилається Замовнику, а статус заявки змінюється на "Виконано".

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

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

Окремо Скаржник звертає увагу на інструкцію по роботі з Dicom-платформою для ролі "Головний лікар Виконавця", яка за своїм змістом підтверджує наявність інтерфейсу керівника та функціоналу контролю за заявками. У документі зазначено, що на робочому столі відображається загальна статистика по заявках. Також передбачено реєстр надісланих заявок Замовника та систему фільтрації, де заявки можна відбирати за ПІБ лікаря виконавця, станом заявки, типом обстеження, терміновістю, лікарем Замовника, пацієнтом, закладом, який направив замовлення, та періодом. Крім того, у документі окремо зазначено, що є відмітка по стану оплати у самій заявці, ургентні візити позначаються окремою іконкою, а також відображається відлік часу, що залишився на виконання. Це прямо відповідає вимогам технічної специфікації щодо перегляду статистики, статусів заявок, історії виконання та взаєморозрахунків, принаймні в частині демонстрації відповідного інтерфейсу та його функціональних можливостей.

Отже, твердження протоколу про нібито повну відсутність підтверджень функціоналу платформи суперечить самим поданим учасником документам. Учасник надав не формальні декларації без змісту, а інструкції зі скріншотами, які підтверджують наявність доступу до платформи, створення заявки, вибір лікаря, роботу з даними пацієнта, завантаження DICOM-досліджень, відображення журналу подій, опрацювання заявки Виконавцем, формування висновку, підписання висновку та зміну статусу заявки.

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

У Протоколі відхилення Замовник зазначає як підставу те, що інформація щодо взаємодії ОП з МІС "відсутня". Однак, як доведено вище, така інформація була фактично наявна у складі Пропозиції у вигляді візуалізованих копій (скріншотів) екранних форм, що містяться у наданих Інструкціях користувача.

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

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

У протоколі лише повторено текст вимоги та зроблено загальний висновок "відсутня інформація".

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

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

У складі Пропозиції Скаржником було надано документ "Довідка згода із Технічним завданням.pdf", у якому Скаржник чітко та беззаперечно гарантує відповідність своєї Пропозиції вимогам додатку 2 Документації, зокрема, і пункту 5.2 щодо автоматичної передачі даних та взаємодії з МІС Замовника.

Надані Скаржником Інструкції користувача візуалізують результати цієї інтеграції (зокрема, автоматичне формування карток пацієнтів та заявок).

Відтак, Пропозиція Скаржника у своїй сукупності повністю відповідала встановленим вимогам Додатку 2 Документації.

Зазначені підстави відхилення є явно недостовірними та не відповідають фактичному змісту Пропозиції Скаржника.

У складі своєї Пропозиції Скаржник завантажив архів "Дайком презентація функціоналу", який містить три повноцінні інструкції користувача для ролей "Лікар Виконавця", "Лікар Замовника" та "Головний лікар Виконавця".

Кожна інструкція включає десятки скріншотів реальних екранних форм платформи (Рис. 1–30) та покрокові текстові описи всіх процесів, що повністю демонструє функціональність онлайн-платформи UNICAM, включаючи інтеграцію з МІС Замовника Таким чином, замість окремих розрізнених скріншотів чи короткого відео Скаржник надав комплексний, структурований матеріал, який значно перевищує мінімальні вимоги тендерної документації. Інструкції з великою кількістю якісних скріншотів та детальними поясненнями є еквівалентним і навіть більш інформативним способом демонстрації функціональності, оскільки дозволяють Замовнику детально вивчити кожен елемент інтерфейсу та послідовність дій. Твердження Замовника про "ненадання" скріншотів/відеопрезентацій не відповідає дійсності.

Скаржник у складі Пропозиції надав документи, що повністю демонструють відповідність вимогам пп. 4, 5.1 та 5.2 додатку 2 Документації.

Зокрема, Скаржник надав файл архів "Дайком презентація функціоналу" (який включає інструкції по роботі з Dicom платформою для ролей "Лікар Виконавця", "Лікар Замовника" та "Головний лікар Виконавця"), де містяться скріншоти екранних форм (Рис.

1-18) та детальні описи процесів, що демонструють функціональність онлайн платформи (ОП) UNICAM, включаючи інтеграцію з Медичною інформаційною системою (МІС) Замовника. Ці документи еквівалентні відео-презентаціям, оскільки ілюструють крок-закроком роботу системи з використанням скріншотів та текстових пояснень.

Надані Скаржником документи, зокрема інструкції по роботі з Dicom платформою (файли "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf ", "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf" та "Інструкція_по_роботі_з_Dicom_платформою_Роль_головний_лікар_Виконавця.pdf"), містять скріншоти екранних форм та детальну інфомрацію на підтвердження відповідності вимогам замовника.

Детальний аналіз відповідності наданого файлу вимогам:

• Автоматична передача даних пацієнта з МІС Замовника до ОП: У файлі "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf" (стор. 6-7, Рис. 7-10) описано процес пошуку/створення пацієнта на основі даних з МІС, з автоматичним заповненням полів заявки (стор. 4-5, Рис. 4-5). Це демонструє інтеграцію та автоматичну передачу даних через синхронізацію з МІС.

• Формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника: У тій же інструкції (стор. 3-8, Рис. 3-11) показано формування заявки з автоматичним заповненням полів пацієнта та лікаря на основі даних з МІС, з перевіркою обов’язкових полів для активації (стор. 8). Скріншоти демонструють процес інтеграції.

• Можливість контролю виконання стану заявки в МІС Замовника: У файлі (стор. 11, Рис. 19; стор. 15-16, Рис. 28-30) описано реєстр заявок з фільтрацією по станам та журнал подій, що синхронізується з МІС у реальному часі для моніторингу. Також у файлі "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf" (стор. 10, Рис. 17-18) показано оновлення статусів після завершення, з інтеграцією в МІС.

• Автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовника:

У файлі "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf" (стор. 10, Рис. 17-18) описано автоматичне надсилання висновку Замовнику після підписання, з інтеграцією в картку пацієнта через PACS та файли (стор. 6). У файлі для Замовника (стор. 14-15, Рис. 25-27) показано перегляд у WEB Viewer, що забезпечує автоматичне отримання в МІС.

Зазначені інструкції містять скріншоти (Рис. 1-30 у різних файлах) та текстові описи, що повністю демонструють функціональність, як вимагає тендерна документація.

Твердження Замовника про "ненадання" не відповідає дійсності та ігнорує надані файли, що є порушенням принципів об’єктивності та недискримінації.

Скаржник наводить детальний аналіз відповідності вимогам на основі наданих інструкцій для ролей користувачів ("Лікар Виконавця", "Лікар Замовника" та "Головний лікар Виконавця"), з посиланнями на конкретні сторінки документів. Аналіз базується на функціональності, продемонстрованій через описи процесів, скріншоти екранних форм та приклади роботи, які, на думку Скаржника, ілюструють реалізацію вимог встановлених Документацією.

1. Відповідність інтерфейсу "Керівника" Інтерфейс "Керівника" відповідає ролі "Головний лікар Виконавця" в інструкції "Інструкція_по_роботі_з_Dicom_платформою_Роль_головний_лікар_Виконавця.pdf". Ця роль забезпечує адміністративний контроль над заявками, статистикою та фільтрацією.

Детальний аналіз:

Перегляд статистики надісланих заявок Замовника: На робочому столі відображається загальна статистика по заявкам (стор. 3, Рис. 2). Це включає кількість надісланих заявок від Замовників, з можливістю переходу до реєстру для детального перегляду (стор. 3-4, Рис. 3-4). Функціональність демонструє агреговані дані, що дозволяють керівнику моніторити обсяг надісланих заявок.

Перегляд статусу виконання заявок Замовника: Реєстр заявок дозволяє переглядати статуси (наприклад, "Виконано", "В роботі" тощо) через фільтрацію по станам (стор. 5, Рис.

6). Також є відмітка по стану оплати (стор. 5, Рис. 7), що інтегрується зі статусом виконання.

Протерміновані заявки виділяються кольором (стор. 6, Рис. 9), забезпечуючи візуальний контроль.

Перегляд історії виконаних описів КТ: Історія заявок, включаючи виконані описи КТ, доступна в реєстрі з фільтрацією по типу обстеження (стор. 5, Рис. 5) та періоду (стор.

7, Рис. 12). Це дозволяє переглядати хронологію виконаних описів, з можливістю вивантаження у .xls для аналізу (стор. 5).

Перегляд стану взаєморозрахунків Замовника: Стан взаєморозрахунків відображається через фільтрацію по стану оплати (стор. 5, Рис. 7), де заявки маркуються як оплачені/неоплачені. Фільтрація по закладу Замовника (стор. 7, Рис. 13) дозволяє агрегувати дані по розрахунках з конкретними Замовниками.

Ці функції демонструються скріншотами екранних форм (наприклад, Рис. 2 на стор.

3 для статистики, Рис. 6-7 на стор. 5 для статусів), що еквівалентно вимозі надання копій/скріншотів.

2. Відповідність інтерфейсу "Лікаря" Інтерфейс "Лікаря" відповідає ролі "Лікар Виконавця" в інструкції "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf". Ця роль фокусується на обробці заявок від Замовників. Детальний аналіз:

Перегляд створених заявок Замовником в роботу: Робота починається з розділу "Заявки на діагностику", де лікар переглядає надіслані заявки (стор. 3, Рис. 2). Далі доступні вкладки для детального перегляду матеріалів заявки ("Дані заявки", "Файли", "PACS") (стор. 6, Рис. 8-9), що дозволяє брати заявки в роботу.

Можливість опису досліджень в системі: Опис досліджень здійснюється через перегляд файлів у форматі DICOM на вкладці "PACS" (стор. 6), з використанням шаблонів для розділів "Опис" та "Висновок" (стор. 8, Рис. 13-14). Це включає завантаження зображень та редагування (стор. 8, п. 1-2).

Створення заключення в системі з накладанням КЕП лікаря: Створення висновку відбувається в розділі "Висновок", з можливістю завантаження .pdf або створення по шаблону (стор. 7, Рис. 11). Після створення натискається "Підписати" для накладання електронного підпису (КЕП) (стор. 7, Рис. 12). Після підпису можливе скасування або вивантаження для додаткового ЕЦП (стор. 10, Рис. 16), з завершенням роботи (стор. 9-10, Рис. 15-18).

Функціональність ілюструється скріншотами (наприклад, Рис. 11-12 на стор. 7 для створення та підпису), що відповідає вимозі демонстрації через скріншоти/відео.

3. Відповідність інтерфейсу "Користувача" Інтерфейс "Користувача" відповідає ролі "Лікар Замовника" в інструкції "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf". Ця роль призначена для створення та моніторингу заявок. Детальний аналіз:

Створення заявок Замовника: Створення нової заявки описано в розділі 2.1 (стор. 38, Рис. 3-11). Це включає заповнення полів, вибір лікаря (стор. 5, Рис. 5-6), створення/пошук пацієнта (стор. 6-7, Рис. 7-10), додавання DICOM-досліджень (стор. 8-11, Рис. 12-18) та інших документів (стор. 12, Рис. 20). Кнопка "Створити заявку" активується після заповнення (стор. 8, Рис. 11).

Перегляд статусів заявок Замовника: Перегляд реєстру заявок доступний у меню "Заявки на діагностику" (стор. 15-16, Рис. 28-29), з фільтрацією по станам (стор. 16, Рис. 30) та терміновості (стор. 16). Також можливий перегляд статусу в журналі подій (стор. 11, Рис.

19) та підписання заявки (стор. 13-14, Рис. 23-24).

Демонстрація через скріншоти (наприклад, Рис. 3-11 на стор. 4-8 для створення, Рис.

28-30 на стор. 15-16 для статусів) відповідає вимогам.

4. Відповідність вимогам до інформаційної взаємодії з іншими системами (5.2) Інструкції демонструють інтеграцію з Медичною інформаційною системою (МІС) Замовника через автоматизовані процеси передачі даних, хоча акцент на ручних кроках для демонстрації. Детальний аналіз:

Автоматична передача даних пацієнта з МІС Замовника до ОП: Дані пацієнта передаються автоматично при створенні заявки, з можливістю пошуку/створення пацієнта на основі даних з МІС (інструкція для "Лікар Замовника", стор. 6-7, Рис. 7-10). Це інтегрується з полями заявки (стор. 4-5, Рис. 4-5).

Формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника: Заявка формується на основі переданих даних, з автоматичним заповненням полів пацієнта та лікаря (стор. 3-8, Рис. 3-11). Процес включає перевірку обов'язкових полів для активації створення (стор. 8).

Можливість контролю виконання стану заявки в МІС Замовника: Контроль статусу заявки можливий через реєстр та журнал подій, що синхронізується з МІС (стор. 11, Рис.

19; стор. 15-16, Рис. 28-30). Статуси оновлюються в реальному часі, дозволяючи інтеграцію з МІС для моніторингу.

Автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовника: Після завершення (підписання висновку), опис автоматично надсилається Замовнику (інструкція для "Лікар Виконавця", стор. 10, Рис. 17-18), з інтеграцією в картку пацієнта МІС через PACS та файли (стор. 6 у "Лікар Виконавця"; стор. 14-15 у "Лікар Замовника", Рис. 25-27 для перегляду в WEB Viewer).

Скаржник наголошує, що функціональність "автоматичної передачі даних з МІС Замовника" та "отримання опису в картку пацієнта у МІСі Замовника" є технологічним процесом двостороннього обміну даними за допомогою API (або протоколів HL7/FHIR). Зі свого боку, онлайн-платформа Скаржника (UNICAM) має реалізований та готовий до роботи шлюз для прийому/відправки таких даних, що доводиться здатністю системи автоматично генерувати заявки та заповнювати дані пацієнтів без ручного вводу.

Відхилення на підставі пункту 44 Особливостей (невідповідність технічній специфікації) є незаконним, оскільки Пропозиція повністю відповідає вимогам.

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

Надані Скаржником документи, зокрема, інструкції по роботі з Dicom платформою (файли "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf ", "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf" та "Інструкція_по_роботі_з_Dicom_платформою_Роль_головний_лікар_Виконавця.pdf"), містять скріншоти екранних форм (Рис. 1-18 у різних файлах) та детальні описи функціональності онлайн платформи UNICAM. Ці документи демонструють технічні аспекти платформи, яка використовується для надання послуг, але не змінюють предмет закупівлі. Вони не стосуються безпосередньо зміни суті послуг (розшифрування, опису та інтерпретації даних), а лише ілюструють інструментарій для їх реалізації, що не призводить до зміни найменування, марки чи моделі предмета закупівлі.

У даному випадку "стверджувана" Замовником "невідповідність" (ненадання окремих скріншотів чи відео-презентацій) є саме такою невідповідністю, виправлення якої не змінює предмет закупівлі, оскільки стосується лише форми демонстрації функціональності платформи, а не суті послуг. Замовник був зобов’язаний надати Скаржнику не менше 24 годин на усунення такої невідповідності шляхом розміщення відповідного повідомлення в електронній системі закупівель.

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

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

Згідно з пунктом 43 Особливостей, у таких випадках Замовник зобов’язаний розмістити повідомлення з вимогою про усунення невідповідностей та надати учаснику не менше 24 годин для їх виправлення. Замовник цим обов’язком знехтував і одразу відхилив пропозицію, чим грубо порушив встановлений порядок та принцип пропорційності.

Замовник зазначає, що рішення про дискваліфікацію (відхилення) Пропозиції Скаржника було прийнято Замовником на підставі невідповідності Пропозиції вимогам пункту 5.2 Додатку 2 Документації.

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

Натомість у Скарзі Скаржник посилається на пункт 5.1 Додатку 2 Документації, наводячи аргументи щодо відповідності його Пропозиції вимогам саме цього пункту.

Замовник зазначає, що пункт 5.1 та пункт 5.2 Додатку 2 містять різні за змістом та правовою природою вимоги, які регулюють окремі аспекти технічної документації.

Відповідно, доводи Скаржника щодо відповідності вимогам пункту 5.1 жодним чином не спростовують встановлену Замовником невідповідність вимогам пункту 5.2 Додатку 2.

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

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

Замовник не зобов’язаний розглядати документи, які не вимагалися Документацією.

Для здійснення своєї діяльності Замовник використовує медичну інформаційну систему Askep.net, що підтверджується договором №1844/44 від 30 січня 2026 року. Ця інформація є загальнодоступною за посиланням UA-2026-01-05-005814-a.

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

У складі Пропозиції Скаржника наявний архів "Дайком презентація функціоналу.rar", що містить файли Інструкція_по_роботі_з_Dicom_платформою_Роль_головний_лікар_Виконавця.pdf, Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf, Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf.

• Щодо наданих аргументів Скаржником в частині "Автоматична передача даних пацієнта з МІС Замовника до ОП:

У файлі "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf" (стор. 6-7, Рис. 7-10) описано процес пошуку/створення пацієнта на основі даних з МІС, з автоматичним заповненням полів заявки (стор. 4-5, Рис. 4-5). Це демонструє інтеграцію та автоматичну передачу даних через синхронізацію з МІС." (В цій частині Замовник наводить знімок).

Рисунки 7-10, 4-5 демонструють процес створення заявки в онлайн платформі Скаржника і не є підтвердженням автоматичної передачі даних пацієнта з Медичної інформаційної системи (МІС) Замовника до ОП, що вимагалось п.5.2. Додатку 2 Документації, а тому у Замовника були підстави для відхилення Пропозиції Скаржника Щодо наданих аргументів Скаржником в частині "Формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника: У тій же інструкції (стор. 3-8, Рис. 3-11) показано формування заявки з автоматичним заповненням полів пацієнта та лікаря на основі даних з МІС, з перевіркою обов’язкових полів для активації (стор. 8).

Скріншоти демонструють процес інтеграції." Так, вищезазначена інструкція містить наступну інформацію (В цій частині Замовник наводить знімок).

Рисунки 3-11 демонструють процес створення заявки в онлайн платформі Скаржника і не є підтвердженням формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника, що вимагалось п.5.2 Додатку 2 Документації, а тому у Замовника були підстави для відхилення Пропозиції Скаржника Щодо наданих аргументів Скаржником в частині "Можливість контролю виконання стану заявки в МІС Замовника: У файлі (стор. 11, Рис. 19; стор. 15-16, Рис. 28-30) описано реєстр заявок з фільтрацією по станам та журнал подій, що синхронізується з МІС у реальному часі для моніторингу.

Також у файлі "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf" (стор. 10, Рис. 17-18) показано оновлення статусів після завершення, з інтеграцією в МІС." Так, вищезазначені інструкції містять наступну інформацію (В цій частині Замовник наводить знімок).

Рисунки 19, 28-30 "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf", знаходяться в пункті 2.2. Додавання досліджень в форматі DICOM та у пункті 2.6. Перегляд заявок на діагностику, тобто демонструють можливість контролю заявки в онлайн платформі Скаржника, а не в МІС Замовника, як того вимагали умови Документації.

Рисунки 17-18 у файлі "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf" розмішені в пункті 6. Завершення роботи з заявкою, та демонструють процес завершення роботи з заявкою Лікаря, який здійснює опис, та не демонструють можливість контролю виконання стану заявки в МІС Замовника чи інтеграції чи синхронізації з МІС Замовника.

Щодо наданих аргументів Скаржником в частині "Автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовника:

У файлі "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf" (стор. 10, Рис. 17-18) описано автоматичне надсилання висновку Замовнику після підписання, з інтеграцією в картку пацієнта через PACS та файли (стор. 6). У файлі для Замовника (стор.

14-15, Рис. 25-27) показано перегляд у WEB Viewer, що забезпечує автоматичне отримання в МІС." Так, вищезазначена інструкція містить наступну інформацію (В цій частині Замовник наводить знімок).

Рисунки 17-18 та сторінка файлу "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Виконавця_1_2.pdf" демонструє процес роботи лікаря з матеріалами заявки в онлайн платформі Скаржника, а не інтеграцію в картку пацієнта через PACS та файли, як стверджує Скаржник.

Рисунки 25-27 файлу "Інструкція_по_роботі_з_Dicom_платформою_Роль_лікар_Замовника_1_2.pdf" демонструють перегляд досліджень у Веб переглядачу, та не демонструє автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовника Пункт 1 Додатку 2 Документації чітко встановлює мету закупівлі.

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

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

Таким чином вимога про порушення процедури закупівлі в частині неправомірного відхилення Пропозиції Скаржника на підставі пункту 44 Особливостей є безпідставною.

У ході розгляду зазначеного питання встановлено наступне.

Відповідно до пункту 1 розділу 3 Документації Пропозиція подається в електронній формі через електронну систему закупівель шляхом заповнення електронних форм з окремими полями, у яких зазначається інформація про ціну, інші критерії оцінки (у разі їх встановлення замовником), інформація від учасника процедури закупівлі про його відповідність кваліфікаційним (кваліфікаційному) критеріям (у разі їх (його) встановлення), наявність/відсутність підстав, установлених у пункті 47 Особливостей і в тендерній документації, та шляхом завантаження необхідних документів, що вимагаються замовником у тендерній документації:

інформацією та/або документами про маркування, протоколи випробувань або сертифікати, що підтверджують відповідність предмета закупівлі встановленим замовником вимогам (у разі встановлення даної вимоги), — згідно з Додатком 2 до тендерної документації.

Відповідно до пункту 6 розділу 3 Документації вимоги до предмета закупівлі (технічні, якісні та кількісні характеристики) згідно з пунктом третім частини другої статті 22 Закону зазначено в Додатку 2 до цієї тендерної документації.

Додаток 1 Документації містить перелік документів та/або інформації, які подаються Учасником процедури закупівлі у складі Пропозиції.

Додаток 2 Документації містить Інформацію про необхідні технічні, якісні та кількісні характеристики предмета закупівлі — технічні вимоги до предмета закупівлі та передбачає, зокрема:

ТЕХНІЧНА СПЕЦИФІКАЦІЯ

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

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

ДК 021:2015 – код 85150000-5 — Послуги діагностичної візуалізації (Послуги з розшифрування, опису та інтерпретації даних досліджень мультизрізової комп’ютерної томографії із застосуванням телемедичних технологій).

5.2. Вимоги до інформаційної взаємодії ОП з іншими системами:

Автоматична передача даних пацієнта з Медичної інформаційної системи (МІС) Замовника до ОП (в складі тендерної пропозиції надати копії (скріншоти) екранних форм/відео-презентації, що демонструють функціональність) Формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника (в складі тендерної пропозиції надати копії (скріншоти) екранних форм/відео-презентації, що демонструють функціональність) ;

Можливість контролю виконання стану заявки в МІС Замовника;

Автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовника.

Для оцінки відповідності тендерної пропозиції Учасника умовам технічної специфікації Замовник створює комісію з представників медичного закладу - Якщо тендерна пропозиція Учасника не відповідає Технічній специфікації тендерної документації замовника, то така тендерна пропозиція буде відхилена, як така, що не відповідає вимогам тендерної документації.

У складі Пропозиції Скаржника міститься, зокрема, документ "Інформація про необхідні технічні, якісні та кількісні характеристики предмета закупівлі — технічні вимоги до предмета закупівлі" (файл Довідка згода із Технічним завданням.pdf), відповідно до якого:

"ТОВ "УКРАЇНСЬКИЙ ПІВНІЧНО-СХІДНИЙ ІНСТИТУТ ПРИКЛАДНОЇ ТА

КЛІНІЧНОЇ МЕДИЦИНИ" цим листом гарантує, та підтверджує згоду із вимогам Технічного завдання закупівлі, згідно Додатку № 2 Тендерної документації, а також те, що учасник їм відповідає та їх виконає, на підтвердження чого вимоги зазначаються нижче:

5.2. Вимоги до інформаційної взаємодії ОП з іншими системами:

- Автоматична передача даних пацієнта з Медичної інформаційної системи (МІС) Замовника до ОП (в складі тендерної пропозиції надати копії (скріншоти) екранних форм/відео-презентації, що демонструють функціональність) - Формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника (в складі тендерної пропозиції надати копії (скріншоти) екранних форм/відеопрезентації, що демонструють функціональність).

- Можливість контролю виконання стану заявки в МІС Замовника;

- Автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовника".

Також у складі Пропозиції Скаржника міститься, зокрема, архівна папка "Дайком презентація функціоналу.rar", у якій містяться, зокрема:

-Інструкція по роботі з Dicom платформою Роль "Лікар Замовника", відповідно до якої, зокрема:

1. Вхід на платформу Потрібно зайти за посиланням: https://unicam.avowiz.com/ та вести свій логін та пароль:

Рис. 1 2. Робота з заявками на діагностику Створення нової заявки на діагностику Переходимо до розділу "Заявки на діагностику" У меню обираємо "Нова заявка" Рис.3 Заповнюємо необхідні поля заявки Рис.4 У полі "Лікар" обираємо зі списку доступних лікарів, Рис.5 якщо потрібного ПІБ лікаря немає, то потрібно додати в меню "Лікарі":

Рис.6 У полі пацієнт можна або створити нового пацієнта за допомогою кнопки "+" Рис. 7 Після того як будуть заповнені обов'язкові поля з зіркою, активується кнопка "Створити пацієнта" Рис.8 або знайти вже створеного раніше через пошук ставши клацнувши два рази лівою кнопкою миші по полю Рис.9 та вести прізвище пацієнта Рис.10 Потрібно заповнити всі поля у заявці, що кнопка створити стала активною Рис.11 Увага! Якщо кнопка внизу форми "Створити заявку" неактивна, то потрібно заповнити всі поля заявки, у тому числі обрати лікаря та пацієнта у відповідних полях … Розділ "Журнал подій" Рис.19 1 – файли досліджень успішно відправлені до PACS 2 – архів файлів успішно завантажено до платформи 3 – успішно додано опис та створена заявка … 2.6 Перегляд реєстру заявок на діагностику Для роботи з реєстром заявок на дослідження потрібно зайти у меню "Заявки на діагностику" та натиснути кнопку пошуку Рис.28 Список досліджень буде відображене:

Рис.29 Можна робити фільтрацію по станам заявок:

Рис.30 По терміновості:

Рис.31 Та по лікарю Замовника:

Рис.32 Також можна фільтрувати по періоду:

Рис.33 Також можна фільтрувати по закладу:

Рис.34 - Інструкція по роботі з Dicom платформою Роль "Лікар Виконавця", відповідно до якої, зокрема:

1. Вхід на платформу Потрібно зайти за посиланням: https://unicam.avowiz.com/ та вести свій логін та пароль:

Рис. 1 2. Робота із заявками на діагностику Переходимо до розділу "Заявки на діагностику" Обраємо лікаря Виконавця Рис.3 Та завантажуємо перелік заявок обираючи "Пошук" Рис.4 Обираємо заявку та призначаємо Рис.5 Рис.6 Після цього беремо в роботу заявку:

Рис.7 3. Робота з матеріалами заявки Далі передивляємось вкладки заявки "Дані заявки", "Файли" та "PACS" Рис.8 На вкладці "Файли" можемо переглянути файли у інших форматах та вивантажити файли у форматі .dicom Рис.9 На вкладці "PACS" Рис.10 4. Створення Висновку далі створюємо Висновок у відповідному розділі завантажуючи готовий висновок у форматі .pdf (п. 1) або створюючи його по шаблону в програмі (п. 2) Рис.11 Після закінчення роботи над Висновком натискаємо кнопку "Підписати" (п.1), також можна видалити Висновок (п.2), переглянути у форматі .pdf (п.3) або змінити його (п.4) Рис.12 Створюємо Висновок:

Завантажуємо при необхідності зображення (п. 1) та використовуємо у разі потреби шаблони для заповнення розділів Опис та Висновок (п. 2) Рис.13 … 6. Завершення роботи із заявкою Після завершення роботи з Висновком натискаємо кнопку "Зберегти" Рис.15 Після підписання Висновку ще можна відмінити підпис (п.1) або вивантажити для накладання ЕЦП цей висновок (п.2), після накладання ЕЦП висновок можна завантажити (п. 3) Рис.16 Після цього завершаємо роботу з заявкою та надсилаємо її замовнику Рис.17 Статус заявки змінюється на "Виконано" Рис.18 -Інструкція по роботі з Dicom платформою Роль "Головний лікар Виконавця".

Документація не містить окремих вимог щодо необхідності надання підтвердження інформаційної взаємодії онлайн платформи саме з медичною інформаційною системою Askep.net.

Враховуючи наведене, у тому числі надані у складі Пропозиції Скаржника документи, Замовник не довів та документально не підтвердив, що онлайн платформа, яку запропоновано учасником не передбачає автоматичну передачу даних пацієнта з Медичної інформаційної системи (МІС) Замовника до ОП, формування заявки Замовника в ОП на підставі переданих даних пацієнта з МІС Замовника, можливість контролю виконання стану заявки в МІС Замовника, автоматичне отримання опису по заявці в картку пацієнта у МІСі Замовника.

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

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

Неправомірно відхиливши Пропозицію Скаржника з підстав, наведених Замовником у протоколі, Замовник порушив вимоги пункту 44 Особливостей.

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

Відповідно до пункту 55 Особливостей оскарження відкритих торгів відбувається відповідно до статті 18 Закону з урахуванням цих особливостей.

Відповідно до частини вісімнадцятої статті 18 Закону за результатами розгляду скарги орган оскарження має право прийняти рішення:

1) про встановлення або відсутність порушень процедури закупівлі (у тому числі порушення порядку оприлюднення або неоприлюднення інформації про процедури закупівлі, передбаченої цим Законом);

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

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

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

Враховуючи наведену вище інформацію, наявні підстави для задоволення Скарги частково.

Враховуючи викладене, керуючись статтею 18 Закону України "Про публічні закупівлі" та Постановою Кабінету Міністрів України від 12.10.2022 № 1178 "Про затвердження особливостей здійснення публічних закупівель товарів, робіт і послуг для замовників, передбачених Законом України "Про публічні закупівлі", на період дії правового режиму воєнного стану в Україні та протягом 90 днів з дня його припинення або скасування", Комісія Антимонопольного комітету України з розгляду скарг про порушення законодавства у сфері публічних закупівель

ПОСТАНОВИЛА:

Зобов'язати Комунальне некомерційне підприємство "Любарська лікарня" Любарської селищної ради Житомирської області (код ЄДРПОУ 01991754) скасувати рішення про відхилення тендерної пропозиції товариства з обмеженою відповідальністю "УКРАЇНСЬКИЙ ПІВНІЧНО-СХІДНИЙ ІНСТИТУТ ПРИКЛАДНОЇ ТА КЛІНІЧНОЇ МЕДИЦИНИ" (код ЄДРПОУ: 31066166) та рішення про визначення товариства з обмеженою відповідальністю "Радіоланс" (код ЄДРПОУ: 46063915) переможцем за процедурою закупівлі — "Код ДК 021:2015: 85150000-5 – Послуги діагностичної візуалізації (Послуги з розшифрування, опису та інтерпретації даних досліджень мультизрізової комп’ютерної томографії із застосуванням телемедичних технологій)", оголошення про проведення якої оприлюднене на веб-порталі Уповноваженого органу за № UA-2026-02-16-013296-a.

Рішення може бути оскаржене до суду у встановлений Законом строк.

Голова Комісії Євгеній БЄГАЛОВ Інна РОМАНЕНКО Члени Комісії Сергій БУРЗАК

Скарга

СКАРГА на рішення про відхилення тендерної пропозиції