-
Відкриті торги з публікацією англійською мовою
-
Безлотова
-
КЕП
Послуги зі створення нового програмного забезпечення та модифікації існуючого програмного забезпечення з автоматизації процесів верифікації відомостей, що містяться в Реєстрах центральної бази даних електронної системи охорони здоров’я з відомостями, що містяться в реєстрах Державної фіскальної служби України (ДФС)
Завершена
10 896 250.00
UAH без ПДВ
мін. крок: 1% або 105 000.00 UAH
мін. крок: 1% або 105 000.00 UAH
Період уточнення:
17.01.2022 20:17 - 11.02.2022 00:00
Відповідь надана
Уточнення до відповіді на питання 27
Номер:
07a71003e880422fb70d0ac309769ffa
Дата опублікування:
02.02.2022 00:33
Опис:
27. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “2.4. Вимоги щодо використання довідників”: “За відсутності необхідного довідника чи класифікатора у процесі первинного інформаційного наповнення Системи та її подальшої експлуатації повинні використовуватись діючі класифікатори, довідники і кодифікатори, які є загальноприйнятими для використання в Україні і супроводжуються відповідними державними установами.”_
-Питання: Чи означає це, що потрібно реалізувати додатковий(і) довідник(и), чи наповнити існуючий(і) довідник(и)? Якщо так, то чи можна отримати для оцінки перелік таких довідників, їх опис, тип розробки (створення чи наповнення довідника)?.__
-Відповідь: точно доповнення довідників, можливо буде потреба в створенні нових. Це буде визначено на етапі розмітки беклогу__
-Уточнююче запитання: Скільки нових довідників потрібно буде створити, скільки з них однорівневих, скільки багаторівневих? Чи потрібно буде реалізовувати CRUD (створення, редагування, оновлення, перегляд запису) для записів нових довідників на UI? Яким чином повинні оновлюватись нові довідники? Дані потрібні для оцінки замовлення.
Відповідь:
Доброго дня! Створити довідники “Джерело валідації” (1 рівень), “Зв’язок реєстру та поліів пацієнта/мед працівника” (1 рівень). Інтерфейс для заповнення не потрібен. Оновлення довідників буде відбуватись за рахунок завантаження / прямого запису в БД
Дата відповіді:
07.02.2022 16:18
Відповідь надана
Уточнення до відповіді на питання 23.2
Номер:
fd823d1d2cbc4090bdbd9e535e7bea70
Дата опублікування:
02.02.2022 00:21
Опис:
23.2. В яких саме процесах є задіяним і потребуватиме скасування існуючий функціонал валідації ІПН по даті народження та статі, а також пацієнтів, що відмовились від ІПН?_
ВІдповідь: у подальших процесах зв’язаних з наданням медичних послуг__
Уточнююче запитання: Ці подальші процеси не вказані в рамках даного ТЗ? Які саме це процеси?
Відповідь:
Доброго дня! Ці процеси за рамками даного ТЗ. Вимога про скасування існуючого функціонала може бути виключена з даного ТЗ на етапі розмітки беклогу, якщо не буде технічної можливості вносити зміни в існуючий функціонал.
Дата відповіді:
07.02.2022 16:15
Відповідь надана
Уточнення до відповіді на питання 20
Номер:
ad9d491f606345a6a7d592f74a622b5e
Дата опублікування:
02.02.2022 00:14
Опис:
20. Питання: Коли, за яких умов повинні запускатись сервіси, описані в розділах 3.1.4.1. та 3.1.4.2. ТЗ (в документі “ТД (інтеграція з ДФС)”)?-
-Ваша Відповідь: 3.1.4.1 для перевірки існуючого РНОКПП в ЕСОЗ, 3.1.4.2 для доповнення запису пацієнта отриманним РНОКПП–
-Уточнююче запитання: “3.1.4.1. Автоматична верифікація відомостей про фізичну особу в Реєстрі пацієнтів ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО” містить крок збагачення даних на схемі. “3.1.4.2. Автоматична верифікація відомостей про фізичну особу в Реєстрі медичних працівників ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО” крок збагачення даних на схемі відсутній. Чи у вашій відповіді вказане призначення саме цих сервісів? Прохання вказати не тільки призначення даних сервісів, а і умови, при яких дані сервіси повинні запускатись.
Відповідь:
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді.
3.1.4.1. Автоматична верифікація відомостей про фізичну особу в Реєстрі пацієнтів ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО” містить крок збагачення даних на схемі. - сервіс верифікації для пацієнтів (сутність person в ЕСОЗ). 3.1.4.2. Автоматична верифікація відомостей про фізичну особу в Реєстрі медичних працівників ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО - сервіс верифікації для медичних працівників (сутність party в ЕСОЗ)
Дата відповіді:
07.02.2022 16:14
Відповідь надана
Уточнення відповідей на запитання 16.4.1 та 17
Номер:
0b4c3ac0d47e4d16b04a6458f5074831
Дата опублікування:
02.02.2022 00:01
Опис:
У відповіді на запитання 16.4.1 ви відповіли, що в “Електронний кабінет мед персоналу (МІС):” потрібно “додати функціонал відображення”. У відповіді на запитання 17 ви відповіли, що змінювати кабінет мед. персоналу не потрібно. Як розуміти дані відповіді? Чи вони не суперечать одна одній?
Відповідь:
Доброго дня!
У відповіді на запитання 16.4.1 ви відповіли, що в “Електронний кабінет мед персоналу (МІС):” потрібно “додати функціонал відображення”. У відповіді на запитання 17 ви відповіли, що змінювати кабінет мед. персоналу не потрібно. Як розуміти дані відповіді? Чи вони не суперечать одна одній?
Відповідь: кабінет МІС розробляють вендори по МІС, зміни в самому кабінеті будуть створені ними, тобто пора рамками даного ТЗ, але метод АРІ потрібен повертати інформацію для відображення статусу.
Дата відповіді:
04.02.2022 17:07
Відповідь надана
Уточнення до питання 15
Номер:
74c18de6bf0248ec871c46a24e519cf4
Дата опублікування:
01.02.2022 23:48
Опис:
15. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами”: “Бізнес вимоги:”: ст. 53:_
Схема доступна за посиланням:
https://drive.google.com/file/d/1QhVFP71qN4FZn1f5yASsIozcVwB580mp/view?usp=sharing_
- Питання: Чи правильно ми розуміємо, що функції, вказані в “SCOPE компонентів” на схемі, вже є реалізованими та їх ендпоінти виклику повинні будуть активуватись в рамках відповідних процесів?__
-Ваша відповідь: Наразі не реалізовано - необхідно реалізувати в частині обміну з ДФС__
-Уточнююче запитання: Тобто не реалізовані механізми реєстрації медичного працівника та реєстрації пацієнта?
Відповідь:
Доброго дня!
15. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами”: “Бізнес вимоги:”: ст. 53:_ Схема доступна за посиланням: https://drive.google.com/file/d/1QhVFP71qN4FZn1f5yASsIozcVwB580mp/view?usp=sharing_ - Питання: Чи правильно ми розуміємо, що функції, вказані в “SCOPE компонентів” на схемі, вже є реалізованими та їх ендпоінти виклику повинні будуть активуватись в рамках відповідних процесів?__ -Ваша відповідь: Наразі не реалізовано - необхідно реалізувати в частині обміну з ДФС__ -Уточнююче запитання: Тобто не реалізовані механізми реєстрації медичного працівника та реєстрації пацієнта?
Відповідь: наразі не реалізовано запит до мікросервісу при реєстрації/оновленні. Самі методи реєстрації/оновлення реалізовані.
Дата відповіді:
04.02.2022 17:06
Відповідь надана
Уточнення до питань 8-9
Номер:
a18849885a8f4ec8a5e627155262338b
Дата опублікування:
01.02.2022 23:18
Опис:
“8. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52: “Мікросервіс електронного обміну даними повинен забезпечувати: … наявність обов’язкових параметрів для запиту до визначених реєстрів; функціонал отримання даних з різних зовнішніх реєстрів згідно з запитами АРІ; …”_
- Питання: Будь ласка, уточніть, які саме реєстри маються на увазі під “визначеними” та під “різними зовнішніми”, які саме параметри потрібно отримувати, та згідно з якими запитами АРІ.__
Ваша Відповідь: ДРАЦСГ (Реєстрація смерті), ДФС (реєстр РНОКПП), ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР). Для кожного з реєстрів існує перелік сервісів ТРЕМБІТА, що описані в окремих ТЗ. В рамках данного ТЗ надано опис сервісів та перелік полів.”__
Питання уточнення: В рамках данного ТЗ надано опис сервісів та перелік полів тільки для ДРФО реєстру фізичних осіб (реєстр РНОКПП). Чи означає це, що в рамках даного ТЗ не замовляється інтеграція з переліченими вами реєстрами ДРАЦСГ (Реєстрація смерті) та ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР)? Чи згаданий вами реєстр ДФС (реєстр РНОКПП) = ДРФО реєстру фізичних осіб (реєстр РНОКПП)?
_____________________________
“9. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52_
“У мікросервісі електронного обміну повинні бути реалізовані наступні вимоги:_
фільтри по сервісах (реєстрах), з яких будуть отримуватись дані;_
наявність переліку обов'язкових параметрів у запиті для кожного окремого сервісу;_
наявність переліку допоміжних параметрів у запиті для кожного окремого сервісу;_
таблицю для стандартизації назв параметрів відповіді для кожного окремого сервісу для співставлення з назвами параметрів ЦБД ЕСОЗ.”_
- Питання: Чи правильно ми розуміємо, що тут мається на увазі веб сторінки опису параметрів сервісів для відображення користувачу та пошук по даним сторінкам? Чи реалізовані такі сторінки для інших сервісів (реєстрів), якщо мікросервіс електронного обміну вже є реалізованим для інших сервісів (реєстрів)?__
Ваша відповідь: мається на увазі доповнення (або створення, якщо дане ТЗ піде в роботу першим) на бекенді мікросервісу, що буде викорстано в рамках обміну з держ реєстрами. Відображення лише результатів обміну у вигляді даних з реєстру чи статусу - кожен випадок описан в ТЗ “__
Питання уточнення: Тобто дані вимоги стосуються тільки бекенда? І для сервісів “3.1.1.1. forDRFOCodeChecking” ст. 39 та “3.1.1.2. FindRegistrationDRFO ” ст. 33 не потрібно реалізовувати вимогу “Має бути забезпечена можливість створювати запити на отримання масиву даних через веб інтерфейс з метою забезпечення повторної верифікації (double check);”?
Відповідь:
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді.
“8. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52: “Мікросервіс електронного обміну даними повинен забезпечувати: … наявність обов’язкових параметрів для запиту до визначених реєстрів; функціонал отримання даних з різних зовнішніх реєстрів згідно з запитами АРІ; …”_
- Питання: Будь ласка, уточніть, які саме реєстри маються на увазі під “визначеними” та під “різними зовнішніми”, які саме параметри потрібно отримувати, та згідно з якими запитами АРІ.__ Ваша Відповідь: ДРАЦСГ (Реєстрація смерті), ДФС (реєстр РНОКПП), ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР). Для кожного з реєстрів існує перелік сервісів ТРЕМБІТА, що описані в окремих ТЗ. В рамках данного ТЗ надано опис сервісів та перелік полів.”
__ Питання уточнення: В рамках данного ТЗ надано опис сервісів та перелік полів тільки для ДРФО реєстру фізичних осіб (реєстр РНОКПП). Чи означає це, що в рамках даного ТЗ не замовляється інтеграція з переліченими вами реєстрами ДРАЦСГ (Реєстрація смерті) та ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР)? Чи згаданий вами реєстр ДФС (реєстр РНОКПП) = ДРФО реєстру фізичних осіб (реєстр РНОКПП)?
Відповідь: так у даному ТЗ мова лише про РНОКПП, інше для розуміння, що мікросервіс має бути доповнено пізніше (для того, щоб були створені можливості розширення функціоналу без зміни протестованого коду). РНОКПП - поле у реєстрі ДРФО, що належить ДФС.
“9. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52_ “У мікросервісі електронного обміну повинні бути реалізовані наступні вимоги:_ фільтри по сервісах (реєстрах), з яких будуть отримуватись дані;_ наявність переліку обов'язкових параметрів у запиті для кожного окремого сервісу;_ наявність переліку допоміжних параметрів у запиті для кожного окремого сервісу;_ таблицю для стандартизації назв параметрів відповіді для кожного окремого сервісу для співставлення з назвами параметрів ЦБД ЕСОЗ.”_
- Питання: Чи правильно ми розуміємо, що тут мається на увазі веб сторінки опису параметрів сервісів для відображення користувачу та пошук по даним сторінкам? Чи реалізовані такі сторінки для інших сервісів (реєстрів), якщо мікросервіс електронного обміну вже є реалізованим для інших сервісів (реєстрів)?__ Ваша відповідь: мається на увазі доповнення (або створення, якщо дане ТЗ піде в роботу першим) на бекенді мікросервісу, що буде викорстано в рамках обміну з держ реєстрами. Відображення лише результатів обміну у вигляді даних з реєстру чи статусу - кожен випадок описан в ТЗ “
__ Питання уточнення: Тобто дані вимоги стосуються тільки бекенда? І для сервісів “3.1.1.1. forDRFOCodeChecking” ст. 39 та “3.1.1.2. FindRegistrationDRFO ” ст. 33 не потрібно реалізовувати вимогу “Має бути забезпечена можливість створювати запити на отримання масиву даних через веб інтерфейс з метою забезпечення повторної верифікації (double check);”?
Відповідь: зауваження вірне - для кабінетів в МІС (пацієнти та мед працівники) - тільки відповідь запиту АРІ з інформацією для відображення статусу верифікації. Для кабінета НСЗУ - і відображення статусу і можливість запиту до реєстрів в реальному часі
Дата відповіді:
04.02.2022 17:06
Відповідь надана
Уточнення до відповідей 7.4-7.6
Номер:
eaa7a103a0bd486eb076d90353ad200a
Дата опублікування:
01.02.2022 22:53
Опис:
Дякуємо за ваші відповіді. Через відсутність форматування тексту на prozoro вийшла невелика плутанина між питаннями-відповідями. Просимо уточнити відповіді щодо наступних запитань:
7.4. Питання: Чи правильно ми зрозуміли, що в усіх 3х електронних кабінетах (в Електронних кабінетах мед персоналу (МІС), керівника або відповідальної особи (МІС), працівника НСЗУ ЦБД ЕСОЗ) вже реалізовано функціонал саме перегляду історії зміни реєстрів пацієнтів та мед. працівників та існуючий функціонал необхідно доповнити відображенням на перегляд історії змін статусів та ознаки джерела інформації?
______________________
7.5. “забезпечувати автоматичну консолідацію та інформаційну цілісність у рамках географічно розподілених даних;”
Питання: Що саме мається на увазі? Які саме дії повинна виконувати система?
_________________________
7.5 зміщене. Питання: Що мається на увазі? Які саме дії повинна виконувати система? “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами”
Ваша відповідь: ЕСОЗ виступає у ролі ЦБД для обміну з Медичними Інформаційними Системами СГуСОЗ. Результат реалізований функціонал має бути доступний для передачі через існуючі методи АРІ - буде необхідно вносити зміни до методів, що буде визначено при розробці.
Уточнююче питання: Який саме функціонал має бути доступним для передачі яких саме даних до яких саме систем через які саме методи АРІ? До яких саме методів необхідно вносити зміни? Чи не протирічить дана відповідь відповіді на питання 7.6?
_____________________________
7.6. “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами”
Попереднє питання: Повинно бути реалізоване окреме АРІ? Якщо так, які саме дані повинні передаватись/отримуватись?
Ваша відповідь: так, дані згідно з наявним у ТЗ описом сервісів “ТРЕМБІТА”
Уточнююче питання: Тобто в даній вимозі маються на увазі тільки сервіси, описані в ТЗ, іншого АРІ реалізовувати не потрібно? І описані в ТЗ сервіси є сервісами системи “ТРЕМБІТА”?
Відповідь:
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді.
7.4. Питання: Чи правильно ми зрозуміли, що в усіх 3х електронних кабінетах (в Електронних кабінетах мед персоналу (МІС), керівника або відповідальної особи (МІС), працівника НСЗУ ЦБД ЕСОЗ) вже реалізовано функціонал саме перегляду історії зміни реєстрів пацієнтів та мед. працівників та існуючий функціонал необхідно доповнити відображенням на перегляд історії змін статусів та ознаки джерела інформації? ______________________
Відповідь: історія змін доступна тільки в кабінеті НСЗУ. Сама історія змін для інших кабінетів не потрібна. Але для всіх трьох кабінеті необхідно реалізувати відображення поточного статусу та ознаки джерела інформації
7.5. “забезпечувати автоматичну консолідацію та інформаційну цілісність у рамках географічно розподілених даних;” Питання: Що саме мається на увазі? Які саме дії повинна виконувати система? _________________________
Відповідь: працівники НСЗУ розподілені між різними містами, кожен повинен мати можливість вибору пацієнтів та мед. працівників, що розташовані на відповідій території
7.5 зміщене. Питання: Що мається на увазі? Які саме дії повинна виконувати система? “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами” Ваша відповідь: ЕСОЗ виступає у ролі ЦБД для обміну з Медичними Інформаційними Системами СГуСОЗ. Результат реалізований функціонал має бути доступний для передачі через існуючі методи АРІ - буде необхідно вносити зміни до методів, що буде визначено при розробці. Уточнююче питання: Який саме функціонал має бути доступним для передачі яких саме даних до яких саме систем через які саме методи АРІ? До яких саме методів необхідно вносити зміни? Чи не протирічить дана відповідь відповіді на питання 7.6?
Відповідь: методи для внесення змін (доповнення ознаками поля, що було верифіковано та джерелом верифікації) - реєстрації/оновлення запису пацієнтів, метод реєстрації/оновлення медичного працівника, метод звільнення медичного працівника, обмін ЕСОЗ-МІС. Методи для обміну з ТРЕМБІТА необхідно створити - тут буде обмін ЕСОЗ - ТРЕМБІТА.
7.6. “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами” Попереднє питання: Повинно бути реалізоване окреме АРІ? Якщо так, які саме дані повинні передаватись/отримуватись? Ваша відповідь: так, дані згідно з наявним у ТЗ описом сервісів “ТРЕМБІТА” Уточнююче питання: Тобто в даній вимозі маються на увазі тільки сервіси, описані в ТЗ, іншого АРІ реалізовувати не потрібно? І описані в ТЗ сервіси є сервісами системи “ТРЕМБІТА”?
Відповідь - так, тут мова про обмін ЕСОЗ-ТРЕМБІТА, цей обмін необхідно реалізувати.
Дата відповіді:
04.02.2022 17:04
Відповідь надана
Запитання до відповіді на питання 3-6
Номер:
acbf868db13844ce9805b01ecc2c05a5
Дата опублікування:
01.02.2022 20:13
Опис:
Доброго дня!
Чи правильно ми розуміємо, що наступна ваша відповідь стосується запитання 4:
"ТЗ на програмний продукт описано з урахуванням усіх потреб НСЗУ, як замовника. В той самий час, НСЗУ не несе відповідальності за можливі зміни в API ДФС. Ці ризики Учасник має враховувати при розрахунку цінової пропозиції для участі в процедурі закупівлі."?
Чи можна отримати відповідь на запитання 3, 5 та 6?
3. Питання: Коли і ким будуть сформовані уточнюючі ТЗ?
Для максимально коректної оцінки вартості предмету закупівлі і гарантування виконання ТЗ потрібно орієнтуватись на максимально точні ТЗ.
Чи повинен учасник тендеру гарантувати виконання уточнюючого ТЗ до ознайомлення з ним?
Яким чином гарантується і чи гарантується виключення випадку розходження уточнюючого ТЗ з ТЗ верхнього рівня?
5. Питання: Чи описані в розділі 3.1. (в документі “ТД (інтеграція з ДФС)”) прикладні програмні інтерфейси (веб-сервіси) є сервісами системи “Трембіта”? Якщо ні, де можна ознайомитись з описом сервісів системи “Трембіта”.
6. Інтеграція. В документі “ТД (інтеграція з ДФС)”: розділ 3.1.3 ст 52 є текст:
“Мікросервіс забезпечує електронний обмін даними у рамках ЦБД ЕСОЗ та з сервісами “ТРЕМБІТА” та/або іншими сторонніми реєстрами. Інтеграції з сервісами “ТРЕМБІТА” та/або іншими сторонніми реєстрами повинні реалізовуватись на базі мікросервісу електронного обміну. Перелік сервісів/сторонніх реєстрів не є вичерпним.”
- Тобто “ТРЕМБІТА” є не єдиною системою, з якою потрібно інтегруватись? Цьому висновку протирічить розділ:
“3.1. Електронна взаємодія через СЕВДЕІР із ДРФО. Верифікація та співставлення отриманих даних із записами ЦБД ЕСОЗ.” ст. 33: “Відповідно до архітектури, ЦБД ЕСОЗ має взаємодіяти з іншими державними реєстрами виключно засобами “Трембіта”. ”
- Питання: Який з даних абзаців є правильним?
- Питання: Для оцінки вартості предмету закупівлі необхідний вичерпний перелік інтеграцій: з яких систем які дані повинні надходити, за якими запитами. Чи зможе замовник надати дану інформацію до 7 лютого?
Відповідь:
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді.
3. Питання: Коли і ким будуть сформовані уточнюючі ТЗ? Для максимально коректної оцінки вартості предмету закупівлі і гарантування виконання ТЗ потрібно орієнтуватись на максимально точні ТЗ. Чи повинен учасник тендеру гарантувати виконання уточнюючого ТЗ до ознайомлення з ним? Яким чином гарантується і чи гарантується виключення випадку розходження уточнюючого ТЗ з ТЗ верхнього рівня?
Відповідь: ТЗ на програмний продукт описано з урахуванням усіх потреб НСЗУ, як замовника. В той самий час, НСЗУ не несе відповідальності за можливі зміни в API ДФС. Ці ризики Учасник має враховувати при розрахунку цінової пропозиції для участі в процедурі закупівлі.
4. Питання: Який строк для надання замовником повної актуальної інформації щодо технічних описів у “ТД (інтеграція з ДФС): розділ 3.1”: сервісу “forDRFOCodeChecking” для асинхронної взаємодії , сервісів “FindRegistrationDRFO” для асинхронної взаємодії, сервісу InfoRNОКPPDRFO для синхронної взаємодії (підтвердження відповідності реєстраційних даних фізичної особи даним Державного реєстру фізичних осіб – платників податків), опису таблиці “DRFO_Database”, склад даних і опис реквізитів.
Відповідь: технічні описи сервісів наявні у ТЗ; опис таблиці “DRFO_Database”, склад даних і опис реквізитів - буде сформовано на етапі розмітки беклогу.
5. Питання: Чи описані в розділі 3.1. (в документі “ТД (інтеграція з ДФС)”) прикладні програмні інтерфейси (веб-сервіси) є сервісами системи “Трембіта”? Якщо ні, де можна ознайомитись з описом сервісів системи “Трембіта”.
Відповідь: Перелік веб-сервісів “Трембіта”(тестові) (https://directory-test.trembita.gov.ua:8443/services)
Перелік веб-сервісів “Трембіта”(PROD) (https://directory-prod.trembita.gov.ua:8443/services)
6. Інтеграція. В документі “ТД (інтеграція з ДФС)”: розділ 3.1.3 ст 52 є текст: “Мікросервіс забезпечує електронний обмін даними у рамках ЦБД ЕСОЗ та з сервісами “ТРЕМБІТА” та/або іншими сторонніми реєстрами. Інтеграції з сервісами “ТРЕМБІТА” та/або іншими сторонніми реєстрами повинні реалізовуватись на базі мікросервісу електронного обміну. Перелік сервісів/сторонніх реєстрів не є вичерпним.” - Тобто “ТРЕМБІТА” є не єдиною системою, з якою потрібно інтегруватись? Цьому висновку протирічить розділ: “3.1. Електронна взаємодія через СЕВДЕІР із ДРФО. Верифікація та співставлення отриманих даних із записами ЦБД ЕСОЗ.” ст. 33: “Відповідно до архітектури, ЦБД ЕСОЗ має взаємодіяти з іншими державними реєстрами виключно засобами “Трембіта”. ” - Питання: Який з даних абзаців є правильним? - Питання: Для оцінки вартості предмету закупівлі необхідний вичерпний перелік інтеграцій: з яких систем які дані повинні надходити, за якими запитами. Чи зможе замовник надати дану інформацію до 7 лютого?
- Питання: Який з даних абзаців є правильним?
Відповідь: 3.1.3 загальні вимоги до мікросервісу; 3.1 вимоги до інтеграції з ДФС
- Питання: Для оцінки вартості предмету закупівлі необхідний вичерпний перелік інтеграцій: з яких систем які дані повинні надходити, за якими запитами. Чи зможе замовник надати дану інформацію до 7 лютого?
Відповідь: в рамках данного ТЗ інтеграція лише з “ТРЕМБІТА”, наразі це єдина система (шина обміну) з якою треба інтегрувати. Необхідні запити для інтеграції з ДФС наявні в ТЗ.
Разом з тим, у разі наявності запитань в подальшому, прохання дотримуватись принципу "одне поле для вводу запитання - одне запитання", в першу чергу - з метою недопущення плутаниці з запитаннями-відповідями, по-друге, слід враховувати, що кількість символів для вводу відповідей (запитань) є обмеженою.
Дата відповіді:
02.02.2022 08:48
Відповідь надана
ТЗ
Номер:
29cad8c750dd4e438be6f1bd691436db
Дата опублікування:
31.01.2022 12:18
Опис:
32. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.1.1. forDRFOCodeChecking ” ст. 39:
“Запит:
Автоматичний запит на отримання масиву даних має здійснюватися з циклічною періодичністю, тобто один раз в часовий проміжок за період часового проміжку між запитами. Цей часовий проміжок повинен бути реалізований конфігураційним параметром (часовий проміжок у кількість N годин/днів); “
32.1. Питання: Яким чином повинні вибиратись дані для вхідних параметрів запиту:
повинні перевірятись всі записи реєстру пацієнтів та реєстру мед працівників
або повинні перевірятись записи, дата зміни яких новіша за дату останньої перевірки
або інший варіант, тоді зазначте, який саме?
32.2. Питання: Перевірка виконується однієї фізичної особи (людини) за один запит? Чи масиву?
“
Має бути забезпечена можливість створювати в Електронному кабінеті НСЗУ запити в на отримання масиву даних через веб інтерфейс з метою забезпечення повторної верифікації (double check);”
32.3. Питання: Яким чином повинні вибиратись дані для вхідних параметрів запиту (запис чи записи про пацієнта чи мед. працівника)?
33. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.1.2. FindRegistrationDRFO ” ст. 33:
“Запит:
…
Має бути забезпечена можливість створювати запити на отримання масиву даних через веб інтерфейс з метою забезпечення повторної верифікації (double check);”
33.1. Питання: Яким чином повинні вибиратись дані для вхідних параметрів запиту (запис чи записи про пацієнта чи мед. працівника)?
33.2. Питання: З якого електронного кабінету повинна бути доступна дана дія?
34. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.1.3. InfoRNОКPPDRFO ” ст. 39:
“Запит:
Має бути забезпечена можливість створювати запити на отримання масиву даних у режимі реального часу з метою забезпечення верифікації даних про РНОКПП фізичних осіб – платників податків онлайн;”
34.1. Питання: Це про запит в межах процесу “3.4. Верифікація відомостей про пацієнта через функціонал електронного кабінету НСЗУ у режимі реального часу щодо валідності/невалідності РНОКПП відповідно до даних у ДРФО”?
35. В документі “ТД (інтеграція з ДФС)”: ТЗ: див. схема 3, ст. 54:
Питання: Чи вже реалізовані механізми збагачення даних, наведені на схемі?
Відповідь:
Доброго дня! Відповідно поставлених питань надаємо наступні відповіді.
32. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.1.1. forDRFOCodeChecking ” ст. 39: “Запит: Автоматичний запит на отримання масиву даних має здійснюватися з циклічною періодичністю, тобто один раз в часовий проміжок за період часового проміжку між запитами. Цей часовий проміжок повинен бути реалізований конфігураційним параметром (часовий проміжок у кількість N годин/днів); “
32.1. Питання: Яким чином повинні вибиратись дані для вхідних параметрів запиту: повинні перевірятись всі записи реєстру пацієнтів та реєстру мед працівників або повинні перевірятись записи, дата зміни яких новіша за дату останньої перевірки або інший варіант, тоді зазначте, який саме?
Відповідь: записи, що не мають ознаки “auto_verified”
32.2. Питання: Перевірка виконується однієї фізичної особи (людини) за один запит? Чи масиву? “ Має бути забезпечена можливість створювати в Електронному кабінеті НСЗУ запити в на отримання масиву даних через веб інтерфейс з метою забезпечення повторної верифікації (double check);”
Відповідь: сервіси дозволяють робити асихронний запит по масиву
32.3. Питання: Яким чином повинні вибиратись дані для вхідних параметрів запиту (запис чи записи про пацієнта чи мед. працівника)?
Відповідь: відповідно з запису про пацієнта та запису про медичного працівника. Назви таблиць та полів буде надано при розмітці беклогу.
33. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.1.2. FindRegistrationDRFO ” ст. 33: “Запит: … Має бути забезпечена можливість створювати запити на отримання масиву даних через веб інтерфейс з метою забезпечення повторної верифікації (double check);”
33.1. Питання: Яким чином повинні вибиратись дані для вхідних параметрів запиту (запис чи записи про пацієнта чи мед. працівника)?
Відповідь: відповідно з запису про пацієнта та запису про медичного працівника. Назви таблиць та полів буде надано при розмітці беклогу.
33.2. Питання: З якого електронного кабінету повинна бути доступна дана дія?
Відповідь: з кабінету працівника НСЗУ
34. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.1.3. InfoRNОКPPDRFO ” ст. 39: “Запит: Має бути забезпечена можливість створювати запити на отримання масиву даних у режимі реального часу з метою забезпечення верифікації даних про РНОКПП фізичних осіб – платників податків онлайн;”
34.1. Питання: Це про запит в межах процесу “3.4. Верифікація відомостей про пацієнта через функціонал електронного кабінету НСЗУ у режимі реального часу щодо валідності/невалідності РНОКПП відповідно до даних у ДРФО”?
Відповідь: так
35. В документі “ТД (інтеграція з ДФС)”: ТЗ: див. схема 3, ст. 54: Питання: Чи вже реалізовані механізми збагачення даних, наведені на схемі?
Відповідь: Збагачення даних потрібно реалізувати
Дата відповіді:
01.02.2022 19:12
Відповідь надана
Уточнення ТЗ
Номер:
60c250c78e3049fd9b7c3d0e1c2f7799
Дата опублікування:
27.01.2022 22:01
Опис:
25. Чи потрібно реалізовувати новий мікросервіс електронного обміну, чи потрібно змінювати вже існуючий.
26. Чи механізм накладання/перевірки КЕП вже реалізований в перелічених Електронних кабінетах і його необхідно перевикористати для вказаних процесів? Чи потрібно реалізовувати новий механізм накладання/перевірки КЕП?
27. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “2.4. Вимоги щодо використання довідників”: “За відсутності необхідного довідника чи класифікатора у процесі первинного інформаційного наповнення Системи та її подальшої експлуатації повинні використовуватись діючі класифікатори, довідники і кодифікатори, які є загальноприйнятими для використання в Україні і супроводжуються відповідними державними установами.”
-Питання: Чи означає це, що потрібно реалізувати додатковий(і) довідник(и), чи наповнити існуючий(і) довідник(и)? Якщо так, то чи можна отримати для оцінки перелік таких довідників, їх опис, тип розробки (створення чи наповнення довідника)?.
28. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ 5.1. Вимоги до інтерфейсу: “Веб-інтерфейс повинен бути адаптованим для використання в усіх сучасних браузерах.”
-Питання: Чи можливо отримати від замовника повний перелік сучасних браузерів, для використання в яких повинен бути адаптований інтерфейс?
29. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “1.2. Передумови, призначення та мета створення”: “Склад послуг.” “Впровадження та налаштування ЦБД ЕСОЗ.”
-Питання: Хіба ЦБД ЕСОЗ не є вже впровадженою? Чи тут мається на увазі впровадження зміненої ЦБД ЕСОЗ?
30. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “5.4. Вимоги до захисту інформації від несанкціонованого доступу” ст. 74
-Питання: Чи ПЗ, що замовляється, повинне стати частиною вже реалізованих та впроваджених систем, які вже мають КСЗІ? Чи для ПЗ, що замовляється, потрібний висновок про відсутність шкідливого коду у його складі та чи такого висновку достатньо?
31. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “5.5. Вимоги до інформаційної безпеки” ст. 75 є вимога:
“Парольні політики для адміністраторів мають визначатись у вигляді налаштувань і автоматично контролюватись системою керування контенту.”
- 31.1. Питання: Чи в замовлення входить поставка системи керування контентом? Чи вже є впроваджена система керування контентом, і якщо так, чи потребує вона змін?
- 31.2. Питання: Чи потрібне розширення існуючої рольової моделі? Чи вже є роль адміністратора в системі?
- 31.3. Питання: Чи вже є реалізованим підхід, описаний в даній вимозі, та чи дана вимога означає, що не потрібно змінювати реалізований підхід?
Відповідь:
Доброго дня! Відповідно поставлених питань надаємо наступні відповіді.
25. Чи потрібно реалізовувати новий мікросервіс електронного обміну, чи потрібно змінювати вже існуючий.
Відповідь: змінювати, мікросервіс буде реалізований в рамках іншого ТЗ
26. Чи механізм накладання/перевірки КЕП вже реалізований в перелічених Електронних кабінетах і його необхідно перевикористати для вказаних процесів? Чи потрібно реалізовувати новий механізм накладання/перевірки КЕП?
Відповіть: функціонал реалізовано
27. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “2.4. Вимоги щодо використання довідників”: “За відсутності необхідного довідника чи класифікатора у процесі первинного інформаційного наповнення Системи та її подальшої експлуатації повинні використовуватись діючі класифікатори, довідники і кодифікатори, які є загальноприйнятими для використання в Україні і супроводжуються відповідними державними установами.” -Питання: Чи означає це, що потрібно реалізувати додатковий(і) довідник(и), чи наповнити існуючий(і) довідник(и)? Якщо так, то чи можна отримати для оцінки перелік таких довідників, їх опис, тип розробки (створення чи наповнення довідника)?.
Відповідь: точно доповнення довідників, можливо буде потреба в створенні нових. Це буде визначено на етапі розмітки беклогу
28. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ 5.1. Вимоги до інтерфейсу: “Веб-інтерфейс повинен бути адаптованим для використання в усіх сучасних браузерах.” -Питання: Чи можливо отримати від замовника повний перелік сучасних браузерів, для використання в яких повинен бути адаптований інтерфейс?
Відповідь: актуальні версії Сhrome, Mozilla, Safari
29. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “1.2. Передумови, призначення та мета створення”: “Склад послуг.” “Впровадження та налаштування ЦБД ЕСОЗ.” -Питання: Хіба ЦБД ЕСОЗ не є вже впровадженою? Чи тут мається на увазі впровадження зміненої ЦБД ЕСОЗ?
Відповідь: мається наувазі впровадження нового модулю та налаштування існуючого
30. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “5.4. Вимоги до захисту інформації від несанкціонованого доступу” ст. 74 -Питання: Чи ПЗ, що замовляється, повинне стати частиною вже реалізованих та впроваджених систем, які вже мають КСЗІ? Чи для ПЗ, що замовляється, потрібний висновок про відсутність шкідливого коду у його складі та чи такого висновку достатньо?
Відповідь: висновку буде достатньо
31. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “5.5. Вимоги до інформаційної безпеки” ст. 75 є вимога: “Парольні політики для адміністраторів мають визначатись у вигляді налаштувань і автоматично контролюватись системою керування контенту.” –
31.1. Питання: Чи в замовлення входить поставка системи керування контентом? Чи вже є впроваджена система керування контентом, і якщо так, чи потребує вона змін? –
Відповідь: система впроваджена, вимог до внесення змін не висувалось
31.2. Питання: Чи потрібне розширення існуючої рольової моделі? Чи вже є роль адміністратора в системі?
Відповідь: потрібне розширення в частині функціоналу, що буде реалізовано в рамках данного ТЗ. Роль адміністратора є
31.3. Питання: Чи вже є реалізованим підхід, описаний в даній вимозі, та чи дана вимога означає, що не потрібно змінювати реалізований підхід?
Відповідь: підхід реалізовано, розробка має відповідати поточній реалізації
Дата відповіді:
01.02.2022 19:08