Кількісні параметри предмета закупівлі

Предмет закупівлі включає всі компоненти (складові), необхідні для налаштування та впровадження ПЗ з затребуваними кількісними характеристиками, а саме:

  1. Надання права на використання програмного забезпечення ПЗ «СКАРБ-ПРО» (або еквівалент) (Річна ліцензія) для 35+ баз даних відділень (Сервер); 
  2. Надання права на використання програмного забезпечення ПЗ «СКАРБ-ПРО» (або еквівалент) (Річна ліцензія) для 42+ додаткових робочих місць (пости, маніпуляційні, тощо)

2. ТЕХНІЧНІ ВИМОГИ ДО ОБСЛУГОВУВАННЯ З ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

 2.1.  Мета, призначення  ПЗ 

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

Основні задачі ПЗ:

  1. Підтримка роботи автоматизованих робочих місць працівників Замовника 
  2. Облік за джерелами фінансування: роздільний облік руху аптечних товарів за джерелами фінансування їх закупівель.
  3. Управління закупівлями: облік закупівель в розрізі постачальників і договорів із контрагентами, за кожною номенклатурною позицією в кількісному і сумарному вираженні.
  4. Управління запасами у відділеннях і кабінетах: персоніфікований облік витрат лікарських препаратів і медичних виробів під час надання медичних послуг, автоматизація процесів узгодження, затвердження та виконання вимог відділень.
  5. Управління запасами в аптеці: предметно-кількісний облік руху номенклатури аптечних товарів за серіями, термінами придатності, документами партії, облік руху аптечних товарів, як загалом на складах, так і в розрізі місць зберігання в середині складу.
  6. Контроль наявності серій, вилучених з обігу, у залишках товарів та контроль відбраковування на етапі надходження лікарських засобів.
  7. Контроль терміну придатності товарів.
  8. Ведення обліку за торговими найменуваннями за кожним лікарським засобом окремо, з зазначенням його назви, дозування, форми випуску (таблетки, ампули тощо), інформації про упаковку (коробки, флакони, туби тощо), назви виробника лікарського засобу, кількості, ціни та суми.
  9. Визначення залишків медикаментів по лікарні в цілому або у конкретному відділенні з можливістю групування по будь-якій ознаці або групам (напр., фіз.розчини, рентген. плівка, наркотичні засоби, тощо)
  10. Автоматичне формування звітів та вивантаження 
  11. Інтеграція з бухгалтерськими системами, аналіз ефективності витрат

2.2. Принцип побудови та ефективності роботи ПЗ.

2.2.1. Вимоги до архітектури

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

ПЗ має бути централізованою системою з єдиною базою даних, що міститься на окремому  сервері, який використовує Замовник. 

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

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

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

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

2.2.2. Вимоги до інтерфейсу користувача

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

Інтерфейс користувача повинен дозволяти оперувати професійними поняттями предметної області лабораторної  діагностики українською мовою.

Інтерфейс користувача повинен підтримувати можливість підтвердження потенційно руйнівних дій користувача з модифікації та відновлення даних.

2.2.3. Вимоги до надійності

ПЗ «СКАРБ-ПРО» повинна забезпечувати безперебійну роботу, із запланованими технічними перервами у межах регламентованих процедур, визначених Замовником. Робота системи має бути організована у цілодобовому режимі.

Швидкість роботи ПЗ повинна бути задовільною  при пікових навантаженнях і при зростанні об’єму баз даних.

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

Критичні дії в ПЗ мають бути із запитом підтвердження перед виконанням відповідної команди (наприклад, перед видаленням інформації або під час переривання режиму обробки тощо).

Вихід з ладу будь-якого робочого місця користувача не має впливати на працездатність ПЗ в цілому.

2.2.4. Вимоги до захисту інформації

Система має забезпечувати авторизацію користувачів. 

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

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

2.2.5. Вимоги щодо застосування систем керування базами даних
  • Рівень зберігання даних в ЛІС повинен бути побудовано на базі сучасних реляційних або не реляційних систем керування базами даних (СКБД). 
  • Можливість працювати на ПК з різною архітектурою і під різними операційними системами.
  • Автоматичний бекап (резервна копія) бази даних.
  • Можливість будь-якого роду експорту даних із бази.
  • Можливість будь-якого роду імпорту даних в базу.
  • Експорт таблиць системи в EXCEL.
  • Вивантаження звітів в форматі Word, EXCEL, DBF
  • Спеціальні утиліти для роботи з базою даних.
  • Реплікація даних (обмін даними між центральною базою та віддаленими при нестабільному каналі зв’язку).

ПЗ повинно мати вбудований редактор друкованих/звітних форм, який повинен бути сумісний з форматами *.doc, *.docx, *.xls, *.xlsx (тобто надавати можливість зберігати файли у наведеному форматі та відкривати раніше створені документи і таблиці у цих форматах, у тому числі для редагування). Редактор повинен зберігати в файловому сховищі ПЗ та відкривати вже збережені документи автоматично, та не потребувати виходу в мережу Інтернет для своєї роботи. Функціонування вбудованого редактору текстів не повинно потребувати встановлення або використання на клієнтському місці або на серверах будь-якого додаткового програмного забезпечення окрім браузера. Використання вбудованого редактору текстів не повинно вимагати придбання додаткових ліцензій або оплати хмарних сервісів.

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

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

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

2.2.6. Вимоги до лінгвістичного забезпечення

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

Всі повідомлення користувачам повинні видаватися українською мовою. Всі поля і відображувані дані в екранних формах повинні бути відображені українською мовою.

2.2.7. Вимоги до адміністрування ПЗ

Підсистема (модуль) адміністрування ПЗ має забезпечувати виконання таких функцій:

  • ведення бази користувачів;
  • створення груп користувачів;
  • визначення доступу до підрозділів в системі у розрізі груп користувачів;
  • визначення доступу до таблиць і дій з даними в таблицях в розрізі груп користувачів;
  • визначення доступу до функцій в системі у розрізі груп користувачів;
  • визначення доступу до звітів в системі у розрізі груп користувачів;
  • налаштування різноманітних схем функціоналу;
  • налаштування автоматичних нумераторів;
  • налаштування значень по замовчуванню;
  • налаштування кольорових маркерів;
  • вибір скріна системи для користувачів;
  • вибір розміру шрифтів для користувачів;
  • вибір мови інтерфейсу для користувачів;
  • вибір мови звітних/друкованих форм для користувачів;
  • можливість зміни структури таблиць в системі для кожного користувача;

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

ПЗ повинно дозволяти налаштовувати свою функціональність під конкретні потреби користувачів.

2.2.8. Вимоги до нормативно-довідкової інформації ПЗ

ПЗ має забезпечувати:

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

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

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

2.2.9. Вимоги до формування звітності в ПЗ

ПЗ повинно мати у своєму складі вбудований конструктор (генератор) звітів, який не вимагає додаткового ліцензування щодо прав його застосування.

ПЗ повинно забезпечувати:

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

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

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

Звіти ПЗ повинні бути доступними для користувача в таких форматах файлів: .dbf, .doc, .docx, .xls, .xlsx.

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

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

Компонент інформаційної взаємодії ПЗ з іншими системами повинен забезпечувати реалізацію таких функцій:

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

ПЗ повинно мати у своєму складі інтегрований поштовий клієнт, який забезпечує відправку електронних листів.

2.2.11 Вимоги до оновлення програмного забезпечення ПЗ

ПЗ повинно забезпечувати стандартний механізм оновлення версій програмного забезпечення або окремих модулів адміністратором.

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

Розробник повинен надавати оновлення версій програмного забезпечення ПЗ для виправлення ймовірних помилок. Оновлення версій програмного забезпечення ПЗ відбувається, згідно умов окремого договору на технічну підтримку програмного забезпечення ПЗ.

2.3. Вимоги до функціоналу системи для автоматизації процесів лікарні.

2.3.1. Вимоги до функціоналу фармацевта-завідуючого аптекою/аптечним складом.
  • Ведення обліку за торговими найменуваннями за кожним лікарським засобом окремо, з зазначенням його назви, дозування, форми випуску (таблетки, ампули тощо), МНН, інформації про упаковку (коробки, флакони, туби тощо), назви виробника лікарського засобу, кількості, ціни та суми.
  • Можливість об’єднання медикаментів за будь-якими групами – з урахуванням потреб бухгалтерії (напр., групи — перев’язувальні матеріали, спирти, скло, наркотики) або медичних потреб (за фармацевтичними групами)
  • Облік товарів у первинній та вторинних упаковках з автоматичним діленням
  • Автоматичне оприбуткування товару (автоматичний імпорт прибуткових накладних постачальників в електронному вигляді) з автоматичним внесенням атрибутів партії товару: серії, терміну придатності, сертифікату якості та його дати, а також номеру та дати реєстраційного посвідчення, терміну дії реєстраційного посвідчення, виробника, закупівельної ціни, суми, строків оплати, номеру контракту.
  • Автоматична звірка накладних з заявками за параметрами: ціна, кількість, зайві позиції
  • Автоматична перевірка анульованих/забракованих серій під час прийому накладної
  • Облік товарів в розрізі джерел фінансування
  • Робота з контрактами: ведення контрактів, контроль залишків товарів по контракту, контроль залишків сум контракту, контроль лімиту використання сум за контрактом
  • Формування видаткових накладних та накладних на переміщення товарів на відділення лікарні на підставі замовлень відділень автоматично та з корегуванням вручну
  • Формування видаткових накладних та накладних на переміщення товарів на відділення лікарні з урахуванням аналогів по МНН, дозуванню та формам випуску.
  • Проведення інвентарізації, в т.ч. вибіркової, за місцями зберігання, по групам товарів, тощо. Проведення інвентаризації за допомогою терміналів збору даних та сканерів штрих-кодів
  • Можливість формування актів списання (з списанням будь-якої кількості лікарського засобу), актів пересорту, накладних на повернення постачальникам
  • Контроль терміну придатності медикаментів: на різний період часу, в тому числі у розрізі залишків у відділеннях
  • Контроль в ПЗ розпоряджень та приписів Державної служби України з лікарських засобів та контролю за наркотиками з можливістю переміщення забракованих серій в зону карантину та повернення до продажу дозволених серій, формуванням накладних на повернення постачальникам
  • Автоматичний розрахунок потреби на підставі історії використання товарів та прогнозу використання, у тому числі з урахуванням:
    • аналогів по МНН на залишках у відділеннях та в аптеці/складі
    • потреби відділень, яка формується на підставі сформованих за вибраний період та не виконаних замовлень відділень, у тому числі з урахуванням МНН
    • залишків товарів за контрактами
    • групової потреби відділень
  • Формування додатків, передбачених Методичними рекомендаціями ведення обліку лікарських засобів та медичних виробів у закладах охорони здоров’я, що затверджені наказом МОЗ № 635 від 09.09.14
  • Облік залишків по договорам – дані по залишкам по специфікації у кількості та сумі (у звіті та інтерфейсі Специфікації)
  • Облік в розрізі Джерел фінансування (крім того, візуалізація в інтерфейсі в Реєстрі прибуткових накладних та вмісті прибуткових та видаткових накладних)
  • Робота з нульовими залишками, в т.ч в розрізі МНН
  • Можливість аналізу товарів, яких немає на залишку для подальшого замовлення
  • Позначення кольором товарів, які протерміновані – в Видаткових накладних та актах списання
  • При імпорті специфікацій до контрактів існує можливість автоматичного створення карток
  • Довідник МНН
  • Звітність повинна не змінюватись за попередні періоди
  • Вивантаження даних в Меддата та Модератор (за умови такої можливості зі сторони Меддати та Модератора)
  • Контроль наявності серій за приписами Держлікслужби
2.3.2. Вимоги до функціоналу старшої медсестри/медсестри
  • Визначення залишків медикаментів по відділенню та на складі з можливістю групування по будь-якій ознаці або групам (напр., фіз.розчини, рентген.плівка, наркотичні засоби, тощо)
  • Можливість розподілу медикаментів у відділенні – по підрозділам відділення
  • Контроль терміну придатності медикаментів: на різний період часу, в тому числі у розрізі залишків у підрозділах відділення
  • Контроль в ПЗ розпоряджень та приписів Державної служби України з лікарських засобів та контролю за наркотиками з можливістю автоматичного переміщення забракованих серій на склад 
  • Формування замовлень на склад та дефектури відділення
  • Формування додатків, передбачених Методичними рекомендаціями ведення обліку лікарських засобів та медичних виробів у закладах охорони здоров’я, що затверджені наказом МОЗ № 635 від 09.09.14
  • Формування звітів по обігу/залишку медикаментів у підрозділах відділення
 2.3.3. ПЗ повинно мати управлінський функціонал 

Обов’язковими довідниками у системі є:

  1. Довідник Товарів
  2. Довідник Види товару
  3. Довідник Умови зберігання
  4. Довідник Аналоги
  5. Довідник Класифікація товарів
  6. Довідник Фірми
  7. Довідник Контракти
  8. Довідник Фізичні особи
  9. Нозологічний довідник
  10. Довідник Товарів за нозологіями
  11. Довідник Джерела фінансування
  12. Додаткові довідники:
    • Виробники
    • Товарна група
    • Штрих-коди
    • Серії
    • Види товару
    • Типи розмірів
    • Умови зберігання
    • Одиниці виміру‥
    • Тощо

Основним довідником є Довідник товарів

У картці товару передбачені такі атрибути:

  • найменування товару;
  • внутрішній код товару;
  • реєстраційний номер і термін реєстрації товару;
  • виробник товару;
  • відношення до рецептурних ЛЗ (безрецептурні, рецептурні, ПКУ);
  • відношення до товарів гострої необхідності;
  • норма оборотності товару;
  • умови зберігання
  • кількість в первинній та вторинній упаковці
  • кількість в заводській упаковці
  • вбудовані інструкції на медикаменти

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

2.3.4. ПЗ повинно мати інтегрований модуль взаємодії з електронним документообігом (ЕДО)
  • ПЗ повинно забезпечувати обмін електронними документами між зовнішніми контрагентами (наприклад, дистриб’юторами);
  • Електронні документи повинні доставлятися в ПЗ, де буде необхідно накладання КЕП, з автоматичним пошуком і розпізнаванням підписанта
2.3.5. ПЗ передбачає можливість інтеграції з сайтом Держлікслужби
  • ПЗ передбачає можливості забезпечувати обмін приписами, офіційними листами з накладанням КЕП уповноваженої особи 
  • Можливість блокування до продажу заборонених серій
  • Підтвердження про вилучення з обороту
  • Звіт про відповідальних осіб
2.3.6. ПЗ повинно мати інтеграцію з бухгалтерськими системами 
  • ПЗ повинно забезпечувати вивантаження даних по руху товарів для подальшого автоматичного формування бухгалтерських проводок в бухгалтерській системі УБС «Парус»
  • ПЗ повинно забезпечувати вивантаження даних по договорам та специфікаціям для подальшого імпорту в УБС «Парус»
  • Після вивантаження даних в ПЗ повинно автоматично бути заблокований період, за який було вивантажено дані

2.4 Вимоги до процесу супроводу впровадженого  ПЗ (завдання з налаштування програмного забезпечення під потреби замовника).

2.4.1. Для забезпечення повноти, коректності, не заперечливості та актуальності даних в ПЗ, в рамках проекту з впровадження ПЗ, необхідно розробити повний пакет експлуатаційної документації.
2.4.2. Документація до ПЗ повинна бути повною, інформативною, зрозумілою, структурованою, зручною для читання, достатньою, однозначною та несуперечливою (повинні використовуватися тотожні терміни, визначення, ідентифікатори тощо).

Документація повинна надаватися Замовникові у електронному вигляді та повинна бути виконана українською мовою.

2.4.3. Інсталяція системи на комп’ютерах Замовника:
  • виконавець повинен провести встановлення ПЗ на серверній системі, що використовується Замовником;
  • налаштування  ПЗ на робочих станціях;
  • виконавець має провести попередні налаштування, наповнення бази даних згідно із вимогами Замовника та можливості проводити випробування та навчання.

ПЗ повинно мати на етапі встановлення бази даних на сервері, що використовується Замовника, еталону базу номенклатури та звітних форм.

2.4.4. Консультації персоналу щодо використання системи:
  • виконавець має провести навчання адміністраторів щодо встановлення клієнтської частини ПЗ;
  • виконавець повинен розробити план та провести навчання працівників, що мають працювати в системі.
  • поточний базовий  консультаційний супровід щодо роботи програмного забезпечення на період дії річної ліцензії відбувається, згідно умов окремого договору на технічну підтримку програмного забезпечення ПЗ.
2.4.5. До складу експлуатаційної документації входять:

Настанова (інструкція) користувача ПЗ, яка повинна включати в себе:

  • опис функцій системи, а також містити покрокові описи дій користувачів для використання цих функцій.; 

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

Примітка: у разі посилання на конкретні торговельну марку чи фірму, патент, конструкцію або тип предмета закупівлі, джерело його походження або виробника, то разом з цим враховувати вираз “або еквівалент”.

Очікувана вартість 445738 грн.