Уточнення до відповіді на питання 27
27. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “2.4. Вимоги щодо використання довідників”: “За відсутності необхідного довідника чи класифікатора у процесі первинного інформаційного наповнення Системи та її подальшої експлуатації повинні використовуватись діючі класифікатори, довідники і кодифікатори, які є загальноприйнятими для використання в Україні і супроводжуються відповідними державними установами.”_ -Питання: Чи означає це, що потрібно реалізувати додатковий(і) довідник(и), чи наповнити існуючий(і) довідник(и)? Якщо так, то чи можна отримати для оцінки перелік таких довідників, їх опис, тип розробки (створення чи наповнення довідника)?.__ -Відповідь: точно доповнення довідників, можливо буде потреба в створенні нових. Це буде визначено на етапі розмітки беклогу__ -Уточнююче запитання: Скільки нових довідників потрібно буде створити, скільки з них однорівневих, скільки багаторівневих? Чи потрібно буде реалізовувати CRUD (створення, редагування, оновлення, перегляд запису) для записів нових довідників на UI? Яким чином повинні оновлюватись нові довідники? Дані потрібні для оцінки замовлення.
Доброго дня! Створити довідники “Джерело валідації” (1 рівень), “Зв’язок реєстру та поліів пацієнта/мед працівника” (1 рівень). Інтерфейс для заповнення не потрібен. Оновлення довідників буде відбуватись за рахунок завантаження / прямого запису в БД
Уточнення відповідей на запитання 16.4.1 та 17
У відповіді на запитання 16.4.1 ви відповіли, що в “Електронний кабінет мед персоналу (МІС):” потрібно “додати функціонал відображення”. У відповіді на запитання 17 ви відповіли, що змінювати кабінет мед. персоналу не потрібно. Як розуміти дані відповіді? Чи вони не суперечать одна одній?
Доброго дня!
У відповіді на запитання 16.4.1 ви відповіли, що в “Електронний кабінет мед персоналу (МІС):” потрібно “додати функціонал відображення”. У відповіді на запитання 17 ви відповіли, що змінювати кабінет мед. персоналу не потрібно. Як розуміти дані відповіді? Чи вони не суперечать одна одній?
Відповідь: кабінет МІС розробляють вендори по МІС, зміни в самому кабінеті будуть створені ними, тобто пора рамками даного ТЗ, але метод АРІ потрібен повертати інформацію для відображення статусу.
Уточнення ТЗ. Інтеграція
3. Питання: Коли і ким будуть сформовані уточнюючі ТЗ? Для максимально коректної оцінки вартості предмету закупівлі і гарантування виконання ТЗ потрібно орієнтуватись на максимально точні ТЗ. Чи повинен учасник тендеру гарантувати виконання уточнюючого ТЗ до ознайомлення з ним? Яким чином гарантується і чи гарантується виключення випадку розходження уточнюючого ТЗ з ТЗ верхнього рівня? 4. Питання: Який строк для надання замовником повної актуальної інформації щодо технічних описів у “ТД (інтеграція з ДФС): розділ 3.1”: сервісу “forDRFOCodeChecking” для асинхронної взаємодії , сервісів “FindRegistrationDRFO” для асинхронної взаємодії, сервісу InfoRNОКPPDRFO для синхронної взаємодії (підтвердження відповідності реєстраційних даних фізичної особи даним Державного реєстру фізичних осіб – платників податків), опису таблиці “DRFO_Database”, склад даних і опис реквізитів. 5. Питання: Чи описані в розділі 3.1. (в документі “ТД (інтеграція з ДФС)”) прикладні програмні інтерфейси (веб-сервіси) є сервісами системи “Трембіта”? Якщо ні, де можна ознайомитись з описом сервісів системи “Трембіта”. 6. Інтеграція. В документі “ТД (інтеграція з ДФС)”: розділ 3.1.3 ст 52 є текст: “Мікросервіс забезпечує електронний обмін даними у рамках ЦБД ЕСОЗ та з сервісами “ТРЕМБІТА” та/або іншими сторонніми реєстрами. Інтеграції з сервісами “ТРЕМБІТА” та/або іншими сторонніми реєстрами повинні реалізовуватись на базі мікросервісу електронного обміну. Перелік сервісів/сторонніх реєстрів не є вичерпним.” - Тобто “ТРЕМБІТА” є не єдиною системою, з якою потрібно інтегруватись? Цьому висновку протирічить розділ: “3.1. Електронна взаємодія через СЕВДЕІР із ДРФО. Верифікація та співставлення отриманих даних із записами ЦБД ЕСОЗ.” ст. 33: “Відповідно до архітектури, ЦБД ЕСОЗ має взаємодіяти з іншими державними реєстрами виключно засобами “Трембіта”. ” - Питання: Який з даних абзаців є правильним? - Питання: Для оцінки вартості предмету закупівлі необхідний вичерпний перелік інтеграцій: з яких систем які дані повинні надходити, за якими запитами. Чи зможе замовник надати дану інформацію до 7 лютого?
Доброго дня!
ТЗ на програмний продукт описано з урахуванням усіх потреб НСЗУ, як замовника. В той самий час, НСЗУ не несе відповідальності за можливі зміни в API ДФС. Ці ризики Учасник має враховувати при розрахунку цінової пропозиції для участі в процедурі закупівлі.
ТЗ
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: Питання: Чи вже реалізовані механізми збагачення даних, наведені на схемі?
Відповідь: Збагачення даних потрібно реалізувати
Уточнююче питання до відповіді на питання 7.5 зміщене
7.5 зміщене. Питання: Що мається на увазі? Які саме дії повинна виконувати система? “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами” _-Ваша відповідь: ЕСОЗ виступає у ролі ЦБД для обміну з Медичними Інформаційними Системами СГуСОЗ. Результат реалізований функціонал має бути доступний для передачі через існуючі методи АРІ - буде необхідно вносити зміни до методів, що буде визначено при розробці. _-Уточнююче питання: Який саме функціонал має бути доступним для передачі яких саме даних до яких саме систем через які саме методи АРІ? До яких саме методів необхідно вносити зміни? Чи не протирічить дана відповідь відповіді на питання 7.6? _-Ваша відповідь:: методи для внесення змін (доповнення ознаками поля, що було верифіковано та джерелом верифікації) - реєстрації/оновлення запису пацієнтів, метод реєстрації/оновлення медичного працівника, метод звільнення медичного працівника, обмін ЕСОЗ-МІС. Методи для обміну з ТРЕМБІТА необхідно створити - тут буде обмін ЕСОЗ - ТРЕМБІТА. __—---Уточнююче запитання нове: Чи правильно ми розуміємо, що: сервіс ЕСОЗ повинен викликати ендпоінти вже реалізованого АРІ системи ТРЕМБІТА, що система ТРЕМБІТА вже має АРІ для методів forDRFOCodeChecking, FindRegistrationDRFO та InfoRNОКPPDRFO (див. Запитання до уточнень відповідей на питання 5-6), та що від виконавця поточного тендеру не вимагається доробка АРІ системи ТРЕМБІТА?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 7.5 зміщене. Питання: Що мається на увазі? Які саме дії повинна виконувати система? “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами” _-Ваша відповідь: ЕСОЗ виступає у ролі ЦБД для обміну з Медичними Інформаційними Системами СГуСОЗ. Результат реалізований функціонал має бути доступний для передачі через існуючі методи АРІ - буде необхідно вносити зміни до методів, що буде визначено при розробці. _-Уточнююче питання: Який саме функціонал має бути доступним для передачі яких саме даних до яких саме систем через які саме методи АРІ? До яких саме методів необхідно вносити зміни? Чи не протирічить дана відповідь відповіді на питання 7.6? _-Ваша відповідь:: методи для внесення змін (доповнення ознаками поля, що було верифіковано та джерелом верифікації) - реєстрації/оновлення запису пацієнтів, метод реєстрації/оновлення медичного працівника, метод звільнення медичного працівника, обмін ЕСОЗ-МІС. Методи для обміну з ТРЕМБІТА необхідно створити - тут буде обмін ЕСОЗ - ТРЕМБІТА. __—---Уточнююче запитання нове: Чи правильно ми розуміємо, що: сервіс ЕСОЗ повинен викликати ендпоінти вже реалізованого АРІ системи ТРЕМБІТА, що система ТРЕМБІТА вже має АРІ для методів forDRFOCodeChecking, FindRegistrationDRFO та InfoRNОКPPDRFO (див. Запитання до уточнень відповідей на питання 5-6), та що від виконавця поточного тендеру не вимагається доробка АРІ системи ТРЕМБІТА? Відповідь: так, описані сервіси існують і праціють, необхідна реалізація ЕСОЗ-ТРЕМБІТА
Уточнююче питання до відповіді на питання 7.5
7.5. “забезпечувати автоматичну консолідацію та інформаційну цілісність у рамках географічно розподілених даних;” _-Питання: Що саме мається на увазі? Які саме дії повинна виконувати система? _-Ваша відповідь: працівники НСЗУ розподілені між різними містами, кожен повинен мати можливість вибору пацієнтів та мед. працівників, що розташовані на відповідній території __—---Уточнююче запитання нове: Чи така можливість вибору (вибору пацієнтів та мед. працівників, що розташовані на відповідній території) вже реалізована в кабінеті НСЗУ та/або в системі ЕСОЗ?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 6. Ваша Відповідь: в рамках данного ТЗ інтеграція лише з “ТРЕМБІТА”, наразі це єдина система (шина обміну) з якою треба інтегрувати. Необхідні запити для інтеграції з ДФС наявні в ТЗ.__ - Уточнююче запитання: Інтеграція з ДФС повинна бути реалізована через систему “Трембіта”? Відповідь: так. Інтеграція ДФС-ТРЕМБІТА реазовано необхідно релізувати інтеграцію ЕСОЗ-ТРЕМБІТА по описаним сервісам. 7.5. “забезпечувати автоматичну консолідацію та інформаційну цілісність у рамках географічно розподілених даних;” _-Питання: Що саме мається на увазі? Які саме дії повинна виконувати система? _-Ваша відповідь: працівники НСЗУ розподілені між різними містами, кожен повинен мати можливість вибору пацієнтів та мед. працівників, що розташовані на відповідній території __—---Уточнююче запитання нове: Чи така можливість вибору (вибору пацієнтів та мед. працівників, що розташовані на відповідній території) вже реалізована в кабінеті НСЗУ та/або в системі ЕСОЗ?
Відповідь: ні, цей функціонал необхідно реалізувати.
Уточнююче питання до відповіді на питання 8
“8. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52: “Мікросервіс електронного обміну даними повинен забезпечувати: … наявність обов’язкових параметрів для запиту до визначених реєстрів; функціонал отримання даних з різних зовнішніх реєстрів згідно з запитами АРІ; …”_ - Питання: Будь ласка, уточніть, які саме реєстри маються на увазі під “визначеними” та під “різними зовнішніми”, які саме параметри потрібно отримувати, та згідно з якими запитами АРІ.__ _-Ваша Відповідь: ДРАЦСГ (Реєстрація смерті), ДФС (реєстр РНОКПП), ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР). Для кожного з реєстрів існує перелік сервісів ТРЕМБІТА, що описані в окремих ТЗ. В рамках данного ТЗ надано опис сервісів та перелік полів.”__ _-Питання уточнення: В рамках данного ТЗ надано опис сервісів та перелік полів тільки для ДРФО реєстру фізичних осіб (реєстр РНОКПП). Чи означає це, що в рамках даного ТЗ не замовляється інтеграція з переліченими вами реєстрами ДРАЦСГ (Реєстрація смерті) та ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР)? Чи згаданий вами реєстр ДФС (реєстр РНОКПП) = ДРФО реєстру фізичних осіб (реєстр РНОКПП)? _-Ваша Відповідь: так у даному ТЗ мова лише про РНОКПП, інше для розуміння, що мікросервіс має бути доповнено пізніше (для того, щоб були створені можливості розширення функціоналу без зміни протестованого коду). РНОКПП - поле у реєстрі ДРФО, що належить ДФС.____________________ ___—Уточнююче питання нове 8.1: В розділах 3.2 та 3.5 на схемах 5 та 8 кроки 6 містять опис “Перевірка даних “Death_Database”, в тому числі й онлайн перевірка у ДРАЦСГ через сервіс GetDeathArByFullNameAndBirthDate”. Питання: Чи входить реалізація даних перевірок в поточну закупівлю? Чи дані перевірки вже реалізовані і в рамках поточної закупівлі повинні тільки викликатись на кроках 6 вказаних процесів?____________________ ___—Уточнююче питання нове 8.2: В розділі 3.5 в вимогах до процесу вказано “Має бути забезпечена база / таблиця(і) зі збереженими результатами кроків процесів реєстрації медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього, яка може бути використана з метою побудови додаткових запитів, аналітичної інформації, експорту даних в структурі, що включає реквізити вихідних баз та бази результат”. Питання: Чи тут справді мається на увазі саме ДРАЦСГ? ____________________ ___—Уточнююче питання нове 8.3: В розділі 3.1.4.1 в “4. Збагачення персональних даних FindRegistrationDRFO:” вказано “Умови опрацювання результатів збагачення персональних даних через сервіс FindRegistrationDRFO: …Якщо у відповіді особу ідентифіковано, але на момент надходження запиту РНОКПП закрито /серія (за наявності) та номер паспорта знято з обліку, у зв’язку з наявністю повідомлення від ДРАЦС про громадян, які померли (RESULT=5), то такому запису пацієнта присвоюється ознака “Ідентифікований, як потенційно померлий”. Статус запису залишається "Активний". Такий запис пацієнта підлягає верифікації на наявність Актового запису про смерть на підставі відомостей, що отримані з ДРАЦСГ. Верифікація відбувається за загальним процесом.” Питання: Чи правильно ми розуміємо, що це опис опрацювання (замовленим в ТЗ сервісом) відповіді, описаної в розділі 3.1.1.2 в “Таблиця 2.2. Опис та структура сервісу “FindRegistrationDRFO”: Довідник результатів обробки: Відповідь не надано з причини: 5 Особу ідентифіковано, але на момент надходження запиту РНОКПП закрито /серія (за наявності) та номер паспорта знято з обліку, у зв’язку з наявністю повідомлення від ДРАЦС про громадян, які померли”?____________________ ___—Уточнююче питання нове 8.4: В розділі 3.1.1.2 в “Таблиця 2.2. Опис та структура сервісу “FindRegistrationDRFO”: Довідник результатів обробки: Відповідь не надано з причини: 5 Особу ідентифіковано, але на момент надходження запиту РНОКПП закрито /серія (за наявності) та номер паспорта знято з обліку, у зв’язку з наявністю повідомлення від ДРАЦС про громадян, які померли” Питання: Чи правильно ми розуміємо, що це опис відповіді вже готового АРІ системи ТРЕМБІТА, яке не повинне ні реалізовуватись, ні дороблятись виконавцем поточного ТЗ, а замовлений в поточному ТЗ сервіс електронної взаємодії повинен опрацьовувати цю відповідь?____________________
оброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 8. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52: “Мікросервіс електронного обміну даними повинен забезпечувати: … наявність обов’язкових параметрів для запиту до визначених реєстрів; функціонал отримання даних з різних зовнішніх реєстрів згідно з запитами АРІ; …”_ - Питання: Будь ласка, уточніть, які саме реєстри маються на увазі під “визначеними” та під “різними зовнішніми”, які саме параметри потрібно отримувати, та згідно з якими запитами АРІ.__ _-Ваша Відповідь: ДРАЦСГ (Реєстрація смерті), ДФС (реєстр РНОКПП), ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР). Для кожного з реєстрів існує перелік сервісів ТРЕМБІТА, що описані в окремих ТЗ. В рамках данного ТЗ надано опис сервісів та перелік полів.”__ _-Питання уточнення: В рамках данного ТЗ надано опис сервісів та перелік полів тільки для ДРФО реєстру фізичних осіб (реєстр РНОКПП). Чи означає це, що в рамках даного ТЗ не замовляється інтеграція з переліченими вами реєстрами ДРАЦСГ (Реєстрація смерті) та ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР)? Чи згаданий вами реєстр ДФС (реєстр РНОКПП) = ДРФО реєстру фізичних осіб (реєстр РНОКПП)? _-Ваша Відповідь: так у даному ТЗ мова лише про РНОКПП, інше для розуміння, що мікросервіс має бути доповнено пізніше (для того, щоб були створені можливості розширення функціоналу без зміни протестованого коду). РНОКПП - поле у реєстрі ДРФО, що належить ДФС.____________________ ___—Уточнююче питання нове 8.1: В розділах 3.2 та 3.5 на схемах 5 та 8 кроки 6 містять опис “Перевірка даних “Death_Database”, в тому числі й онлайн перевірка у ДРАЦСГ через сервіс GetDeathArByFullNameAndBirthDate”. Питання: Чи входить реалізація даних перевірок в поточну закупівлю? Чи дані перевірки вже реалізовані і в рамках поточної закупівлі повинні тільки викликатись на кроках 6 вказаних процесів?____________________ ___
Відповідь: реалізація перевірки у ДРАЦСГ поза даного ТЗ. Перевірки ще не реалізовані, також триває тендер. В рамках поточної закупівлі викликати перевірки ДРАЦСГ не потрібно.
—Уточнююче питання нове 8.2: В розділі 3.5 в вимогах до процесу вказано “Має бути забезпечена база / таблиця(і) зі збереженими результатами кроків процесів реєстрації медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього, яка може бути використана з метою побудови додаткових запитів, аналітичної інформації, експорту даних в структурі, що включає реквізити вихідних баз та бази результат”. Питання: Чи тут справді мається на увазі саме ДРАЦСГ?
Відповідь: вірно, має бути ДРФО
____________________ ___—Уточнююче питання нове 8.3: В розділі 3.1.4.1 в “4. Збагачення персональних даних FindRegistrationDRFO:” вказано “Умови опрацювання результатів збагачення персональних даних через сервіс FindRegistrationDRFO: …Якщо у відповіді особу ідентифіковано, але на момент надходження запиту РНОКПП закрито /серія (за наявності) та номер паспорта знято з обліку, у зв’язку з наявністю повідомлення від ДРАЦС про громадян, які померли (RESULT=5), то такому запису пацієнта присвоюється ознака “Ідентифікований, як потенційно померлий”. Статус запису залишається "Активний". Такий запис пацієнта підлягає верифікації на наявність Актового запису про смерть на підставі відомостей, що отримані з ДРАЦСГ. Верифікація відбувається за загальним процесом.” Питання: Чи правильно ми розуміємо, що це опис опрацювання (замовленим в ТЗ сервісом) відповіді, описаної в розділі 3.1.1.2 в “Таблиця 2.2. Опис та структура сервісу “FindRegistrationDRFO”: Довідник результатів обробки: Відповідь не надано з причини: 5 Особу ідентифіковано, але на момент надходження запиту РНОКПП закрито /серія (за наявності) та номер паспорта знято з обліку, у зв’язку з наявністю повідомлення від ДРАЦС про громадян, які померли”?
Відповідь: так
—Уточнююче питання нове 8.4: В розділі 3.1.1.2 в “Таблиця 2.2. Опис та структура сервісу “FindRegistrationDRFO”: Довідник результатів обробки: Відповідь не надано з причини: 5 Особу ідентифіковано, але на момент надходження запиту РНОКПП закрито /серія (за наявності) та номер паспорта знято з обліку, у зв’язку з наявністю повідомлення від ДРАЦС про громадян, які померли” Питання: Чи правильно ми розуміємо, що це опис відповіді вже готового АРІ системи ТРЕМБІТА, яке не повинне ні реалізовуватись, ні дороблятись виконавцем поточного ТЗ, а замовлений в поточному ТЗ сервіс електронної взаємодії повинен опрацьовувати цю відповідь?____________________
Відповідь: так
Документи для участі в тендері
1 Питання: Який саме документ та які вимоги до його наповнення має бути наданий учасником тендеру, відповідно до вимоги “Учасники процедури закупівлі повинні надати у складі тендерних пропозицій інформацію та документи, які підтверджують відповідність тендерної пропозиції учасника технічним, якісним, кількісним та іншим вимогам до предмета закупівлі, установленим замовником (згідно Додатку №3 цієї документації).”?
Доброго дня!
Згідно пункту 3 Додатку 4 (Перелік документів, які повинні бути завантажені учасником у складі тендерної пропозиції):
"3. Інформація та документи про необхідні технічні, якісні та кількісні характеристики предмета закупівлі згідно Додатку 3 до тендерної документації у тому числі:
- Згода з умовами та вимогами, які визначені у технічній специфікації (Додатку 3 до тендерної документації) та гарантування їх виконання у вигляді підписаної технічної специфікації або у вигляді окремої довідки-згоди."
Уточнення ТЗ
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. Питання: Чи вже є реалізованим підхід, описаний в даній вимозі, та чи дана вимога означає, що не потрібно змінювати реалізований підхід?
Відповідь: підхід реалізовано, розробка має відповідати поточній реалізації
Вже реалізований функціонал
15. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами”: “Бізнес вимоги:”: ст. 53: Схема доступна за посиланням: https://drive.google.com/file/d/1QhVFP71qN4FZn1f5yASsIozcVwB580mp/view?usp=sharing - Питання: Чи правильно ми розуміємо, що функції, вказані в “SCOPE компонентів” на схемі, вже є реалізованими та їх ендпоінти виклику повинні будуть активуватись в рамках відповідних процесів?
Доброго дня!
Наразі не реалізовано - необхідно реалізувати в частині обміну з ДФС
Запитання до уточнень відповідей на питання 5-6
5. Питання: Чи описані в розділі 3.1. (в документі “ТД (інтеграція з ДФС)”) прикладні програмні інтерфейси (веб-сервіси) є сервісами системи “Трембіта”? Якщо ні, де можна ознайомитись з описом сервісів системи “Трембіта”._ ---Ваша Відповідь: Перелік веб-сервісів “Трембіта”(тестові) (https://directory-test.trembita.gov.ua:8443/services) Перелік веб-сервісів “Трембіта”(PROD) (https://directory-prod.trembita.gov.ua:8443/services)__ ---Уточнююче запитання: Чи правильно ми розуміємо, що наведені в ТЗ описи сервісів взаємодії з ДФС - це однойменні сервіси системи “Трембіта”? Якщо так, тоді - сервісу forDRFOCodeChecking відповідає який з результатів пошуку ttps://directory-prod.trembita.gov.ua:8443/search?query=forDRFOCodeChecking ? - які сервіси системи “Трембіта” відповідають сервісам FindRegistrationDRFO та InfoRNОКPPDRFO? Чому пошук по назві даних сервісів не дає результатів?________________________________ 6. Ваша Відповідь: в рамках данного ТЗ інтеграція лише з “ТРЕМБІТА”, наразі це єдина система (шина обміну) з якою треба інтегрувати. Необхідні запити для інтеграції з ДФС наявні в ТЗ.__ - Уточнююче запитання: Інтеграція з ДФС повинна бути реалізована через систему “Трембіта”?
Доброго дня! InfoRNОКPPDRFO - https://directory-test.trembita.gov.ua:8443/search?query=InfoRNOKPPDRFO
FindRegistrationDRFO - https://directory-test.trembita.gov.ua:8443/SEVDEIR-TEST/GOV/43005393/53_DPS_DRFO_test_prod/FindRegistrationDRFOAnswer
Уточнення до питання 15
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 компонентів” на схемі, вже є реалізованими та їх ендпоінти виклику повинні будуть активуватись в рамках відповідних процесів?__ -Ваша відповідь: Наразі не реалізовано - необхідно реалізувати в частині обміну з ДФС__ -Уточнююче запитання: Тобто не реалізовані механізми реєстрації медичного працівника та реєстрації пацієнта?
Відповідь: наразі не реалізовано запит до мікросервісу при реєстрації/оновленні. Самі методи реєстрації/оновлення реалізовані.
Права доступу та авторизація
10. Права доступу. В документі “ТД (інтеграція з ДФС)”: в розділі “5.9. Вимоги до інформаційного забезпечення” ст. 76 є текст: “ПП повинен мати властивості інтегрованого інформаційного середовища: забезпечувати розподіл і надання прав доступу заснованих на рольовому або іншому подібному принципі;” в розділі “2.1. Ролі користувачів Системи” ст. 31 є текст: “В рамках Системи має бути налаштована рольова модель користувачів з розмежуванням доступу до записів пацієнтів та медичних працівників та для роботи з Реєстром пацієнтів ЦБД ЕСОЗ та Реєстром медичних працівників ЦБД ЕСОЗ, що інтегрована до існуючої рольової моделі ЦБД ЕСОЗ. Ведення реєстру користувачів та призначення їм ролей проводиться в системі ЦБД ЕСОЗ.” - 10.1. Питання: Тут “ПП” та “Система” - це ЦБД ЕСОЗ? - 10.2. Питання: Чи мається на увазі розмежування прав доступу до даних в ЦБД ЕСОЗ? Якщо так, то чи вже реалізоване розмежування прав доступу до даних реєстру пацієнтів та реєстру мед. працівників? Якщо так, тоді що саме в даному розмежуванні доступу необхідно змінити/реалізувати? - 10.3. Питання: Чи мається на увазі доступ до функцій системи ЦБД ЕСОЗ? Тоді до яких саме функцій розмежування доступу має бути додано/змінено? Чи правильно ми розуміємо, що повинно бути додано 3 окремі доступи до трьох нових операцій: Ручного верифікації користувачем пацієнта зі списку неверифікованих пацієнтів через Електронний кабінет мед персоналу (МІС), Ручного верифікації мед. працівника зі списку неверифікованих працівників через Електронний кабінет керівника або відповідальної особи (МІС), Ручної верифікації пацієнта через Електронний кабінет працівника НСЗУ ЦБД ЕСОЗ. - 10.4. Питання: Чи мається на увазі розмежування доступу до даних таблиці “DRFO_Database”? Якщо так, чи має сенс таке розмежування, враховуючи питання 12 та 13? 11. Авторизація. В документі “ТД (інтеграція з ДФС)”: в розділі “2.2. Вимоги щодо авторизації користувачів” є абзац “Авторизація користувачів має здійснюватись відповідно до загальних правил та політик авторизації ЦБД ЕСОЗ. Особливих вимог щодо авторизації користувачів в рамках Системи не передбачається.” - Питання: Чи правильно ми розуміємо, що: - 11.1. Кожен з перелічених Електронних кабінетів (мед персоналу (МІС), керівника або відповідальної особи (МІС), працівника НСЗУ ЦБД ЕСОЗ) вже має авторизацію користувача, існуючий процес авторизації користувача не потребує зміни та додавання нової авторизації не потрібне? - 11.2. Авторизація в ЦБД ЕСОЗ вже реалізована та не потребує зміни? - 11.3. Єдине, що потрібно реалізувати стосовно авторизації користувача в межах закупівлі, - це не процес авторизації чи його зміна, а сповіщення, яке повинне відображатись користувачу після авторизації, відповідно до процесу див. розділ “3.6. Перевірка відомостей про медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ щодо валідності/невалідності РНОКПП відповідно до даних, що отримані під час електронної взаємодії з ДРФО”: “Якщо керівником та/або відповідальною особою особою СГуСОЗ в термін N днів не забезпечено опрацювання запиту на верифікацію РНОКПП медичного працівника, то такий медичний працівник під час авторизації в ЦБД ЕСОЗ має отримувати сповіщення про необхідність обробки запиту щодо уточнення з боку керівника та/або уповноваженої особи протягом Х днів, в іншому випадку обліковий запис медичного працівника може бути деактивовано.”? 12. Питання: В таблиці “DRFO_Database” чи не може працівник мед закладу бути і пацієнтом одночасно? Якщо може, то в такому разі в таблиці повинно бути два записи чи один? 13. В документі “ТД (інтеграція з ДФС)”: ТЗ розділ “3.3. Верифікація відомостей пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ медичним працівником щодо відповідності РНОКПП та паспортних даних за результатами перевірки у ДРФО” ст. 62 містить: “Об'єднати записи пацієнта за наявності відповідного скоупу прав (*тільки об’єднання ідентифікованого пацієнта з неідентифікованим медичними працівниками, що надають послуги вторинної (спеціалізованої) медичної допомоги).” - 13.1. Питання: Користувачу для порівняння повинні відображатись і дані пацієнта і дані мед працівника? - 13.2. Питання: Чи дії Користувача повинні змінювати дані в таблиці DRFO_Database? - 13.3. Питання: Чи дії Користувача повинні вносити зміни безпосередньо в реєстр пацієнтів? - 13.4. Питання: Яким чином виконується об’єднання? Чи вносяться зміни в реєстр мед. працівників? 14. В документі “ТД (інтеграція з ДФС)”: ТЗ розділ “3.3. Верифікація відомостей пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ медичним працівником щодо відповідності РНОКПП та паспортних даних за результатами перевірки у ДРФО” ст. 62 “У результаті верифікації та коригування персональних даних пацієнта медичним працівником скасовується ознака “auto_not_verifired”” - Питання: Чи правильно ми зрозуміли, що після “верифікації” (зміни) запису Користувачем, система вже не повинна верифікувати ІПН особи, тобто повинна дозволяти Користувачу вносити будь що?
Доброго дня! Відповідно поставлених питань надаємо наступні відповіді.
10. Права доступу. В документі “ТД (інтеграція з ДФС)”: в розділі “5.9. Вимоги до інформаційного забезпечення” ст. 76 є текст: “ПП повинен мати властивості інтегрованого інформаційного середовища: забезпечувати розподіл і надання прав доступу заснованих на рольовому або іншому подібному принципі;” в розділі “2.1. Ролі користувачів Системи” ст. 31 є текст: “В рамках Системи має бути налаштована рольова модель користувачів з розмежуванням доступу до записів пацієнтів та медичних працівників та для роботи з Реєстром пацієнтів ЦБД ЕСОЗ та Реєстром медичних працівників ЦБД ЕСОЗ, що інтегрована до існуючої рольової моделі ЦБД ЕСОЗ. Ведення реєстру користувачів та призначення їм ролей проводиться в системі ЦБД ЕСОЗ.”
10.1. Питання: Тут “ПП” та “Система” - це ЦБД ЕСОЗ? –
Відповідь: так
10.2. Питання: Чи мається на увазі розмежування прав доступу до даних в ЦБД ЕСОЗ? Якщо так, то чи вже реалізоване розмежування прав доступу до даних реєстру пацієнтів та реєстру мед. працівників? Якщо так, тоді що саме в даному розмежуванні доступу необхідно змінити/реалізувати? –
Відповідь: розмежування доступу реалізовано, необхідно перевикористати рольову модель для доступу до даних таблиці “DRFO_Database”
10.3. Питання: Чи мається на увазі доступ до функцій системи ЦБД ЕСОЗ? Тоді до яких саме функцій розмежування доступу має бути додано/змінено? Чи правильно ми розуміємо, що повинно бути додано 3 окремі доступи до трьох нових операцій: Ручного верифікації користувачем пацієнта зі списку неверифікованих пацієнтів через Електронний кабінет мед персоналу (МІС), Ручного верифікації мед. працівника зі списку неверифікованих працівників через Електронний кабінет керівника або відповідальної особи (МІС), Ручної верифікації пацієнта через Електронний кабінет працівника НСЗУ ЦБД ЕСОЗ.
Відповідь: так необхідно додати до існуючих ролей нові доступи
10.4. Питання: Чи мається на увазі розмежування доступу до даних таблиці “DRFO_Database”? Якщо так, чи має сенс таке розмежування, враховуючи питання 12 та 13?
Відповідь: так, тому що потрібна доробка існуючих кабінетів
11. Авторизація. В документі “ТД (інтеграція з ДФС)”: в розділі “2.2. Вимоги щодо авторизації користувачів” є абзац “Авторизація користувачів має здійснюватись відповідно до загальних правил та політик авторизації ЦБД ЕСОЗ. Особливих вимог щодо авторизації користувачів в рамках Системи не передбачається.” - Питання: Чи правильно ми розуміємо, що: -
11.1. Кожен з перелічених Електронних кабінетів (мед персоналу (МІС), керівника або відповідальної особи (МІС), працівника НСЗУ ЦБД ЕСОЗ) вже має авторизацію користувача, існуючий процес авторизації користувача не потребує зміни та додавання нової авторизації не потрібне? –
Відповідь: Так
11.2. Авторизація в ЦБД ЕСОЗ вже реалізована та не потребує зміни? –
Відповідь: Так
11.3. Єдине, що потрібно реалізувати стосовно авторизації користувача в межах закупівлі, - це не процес авторизації чи його зміна, а сповіщення, яке повинне відображатись користувачу після авторизації, відповідно до процесу див. розділ “3.6. Перевірка відомостей про медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ щодо валідності/невалідності РНОКПП відповідно до даних, що отримані під час електронної взаємодії з ДРФО”: “Якщо керівником та/або відповідальною особою особою СГуСОЗ в термін N днів не забезпечено опрацювання запиту на верифікацію РНОКПП медичного працівника, то такий медичний працівник під час авторизації в ЦБД ЕСОЗ має отримувати сповіщення про необхідність обробки запиту щодо уточнення з боку керівника та/або уповноваженої особи протягом Х днів, в іншому випадку обліковий запис медичного працівника може бути деактивовано.”?
12. Питання: В таблиці “DRFO_Database” чи не може працівник мед закладу бути і пацієнтом одночасно? Якщо може, то в такому разі в таблиці повинно бути два записи чи один?
ВІдповідь: так може бути, в таблиці має бути два записи для сутності person пацієнта та party - мед працівника
13. В документі “ТД (інтеграція з ДФС)”: ТЗ розділ “3.3. Верифікація відомостей пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ медичним працівником щодо відповідності РНОКПП та паспортних даних за результатами перевірки у ДРФО” ст. 62 містить: “Об'єднати записи пацієнта за наявності відповідного скоупу прав (*тільки об’єднання ідентифікованого пацієнта з неідентифікованим медичними працівниками, що надають послуги вторинної (спеціалізованої) медичної допомоги).” –
13.1. Питання: Користувачу для порівняння повинні відображатись і дані пацієнта і дані мед працівника? –
Відповідь: ні, тільки дані пацієнта
13.2. Питання: Чи дії Користувача повинні змінювати дані в таблиці DRFO_Database? –
ВІдповідь: дані в таблиці повинні змінюватись тільки в результаті обміну
13.3. Питання: Чи дії Користувача повинні вносити зміни безпосередньо в реєстр пацієнтів? –
Відповідь: дії лікаря та працівника НСЗУ через відповідні кабінети
13.4. Питання: Яким чином виконується об’єднання? Чи вносяться зміни в реєстр мед. працівників?
Відповідь: існує функціонал ручного мапінгу, його потрібно використовувати
14. В документі “ТД (інтеграція з ДФС)”: ТЗ розділ “3.3. Верифікація відомостей пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ медичним працівником щодо відповідності РНОКПП та паспортних даних за результатами перевірки у ДРФО” ст. 62 “У результаті верифікації та коригування персональних даних пацієнта медичним працівником скасовується ознака “auto_not_verifired”” - Питання: Чи правильно ми зрозуміли, що після “верифікації” (зміни) запису Користувачем, система вже не повинна верифікувати ІПН особи, тобто повинна дозволяти Користувачу вносити будь що?
ВІдповідь: ні, після зміни запису пацієнта повина бути ознака “verification_needed
UI ЦБД ЄСОЗ
36. Питання: На схемі 5 https://drive.google.com/file/d/15eYm7v6UQ7mXs1LKQkDaW6E-2l3Z3vPY/view кроки 5.20 та 5.21 виконуються в пулі “ЦБД ЄСОЗ” користувачем? Якщо так, то через який UI (інтерфейс користувача) повинні виконуватись дані кроки?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 36. Питання: На схемі 5 https://drive.google.com/file/d/15eYm7v6UQ7mXs1LKQkDaW6E-2l3Z3vPY/view кроки 5.20 та 5.21 виконуються в пулі “ЦБД ЄСОЗ” користувачем? Якщо так, то через який UI (інтерфейс користувача) повинні виконуватись дані кроки?
Відповідь: так, це існуючий функціонал, поза рамками даної закупівлі
Електронні кабінети.
17. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “2.3. Необхідний функціонал для роботи користувачів” ст.31 “Для медичного працівника через електронний кабінет медичного працівника (реалізацію функціоналу електронного кабінету медичного працівника забезпечує МІС)” - Питання: Чи означає це, що доробку Електронного кабінету мед працівника виконувати не потрібно? Якщо так, тоді яким чином реалізувати доступ з даного кабінету до нового функціоналу
Доброго дня!
Не потрібно
Уточнення ТС та ТЗ
2. В документі “ТД (інтеграція з ДФС)”: Додаток 3: ТЕХНІЧНА СПЕЦИФІКАЦІЯ: “2. Вимоги до Предмету закупівлі: 2.1. Необхідно врахувати, що створення медичних записів (у частині реєстрації, взаємодії, виписки направлення та рецепту), а також робота персоналу ЗОЗ та аптек з пацієнтом в ЕСОЗ повинна відбуватися за наступними процесами. https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583402851/Medical+Events https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583402225/Medical+events+Technical+Documentation https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583402212/Service+Requests https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/616792094/Persons https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/583404015/Create+Medication+Request+BP” -Питання: Чи входить в закупівлю реалізація або зміна перелічених процесів?
Доброго дня!
Це враховано в іншому попередньому ТЗ, що вже реалізовано
Уточнення до питань 8-9
“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);”?
Відповідь: зауваження вірне - для кабінетів в МІС (пацієнти та мед працівники) - тільки відповідь запиту АРІ з інформацією для відображення статусу верифікації. Для кабінета НСЗУ - і відображення статусу і можливість запиту до реєстрів в реальному часі
Запитання до відповіді на питання 3-6
Доброго дня! Чи правильно ми розуміємо, що наступна ваша відповідь стосується запитання 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 лютого?
Відповідь: в рамках данного ТЗ інтеграція лише з “ТРЕМБІТА”, наразі це єдина система (шина обміну) з якою треба інтегрувати. Необхідні запити для інтеграції з ДФС наявні в ТЗ.
Разом з тим, у разі наявності запитань в подальшому, прохання дотримуватись принципу "одне поле для вводу запитання - одне запитання", в першу чергу - з метою недопущення плутаниці з запитаннями-відповідями, по-друге, слід враховувати, що кількість символів для вводу відповідей (запитань) є обмеженою.
Уточнення до відповіді на питання 20
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 в ЕСОЗ)
Електронні кабінети.
Питання: Чи правильно ми зрозуміли, що: 16.1. Електронний кабінет мед персоналу (МІС), Електронний кабінет керівника або відповідальної особи (МІС) - це існуючі, вже впроваджені електронні кабінети системи МІС? 16.2. Електронний кабінет працівника НСЗУ ЦБД ЕСОЗ - існуючий кабінет ЦБД ЕСОЗ? 16.3. МІС та ЦБД ЕСОЗ - це різні системи? 16.4. Перелічені Електронні кабінети потрібно доопрацювати наступним чином: 16.4.1. Електронний кабінет мед персоналу (МІС): додати новий функціонал відображення та роботи з переліком неверифікованих пацієнтів (які потребують ручної обробки), змінити існуючі процеси: реєстрації пацієнта, редагування запису реєстру пацієнтів, об’єднання записів (ідентифікованого пацієнта з неідентифікованим медичними працівниками)? Чи є перелічені процеси вже реалізованими і, якщо так, то через який(і) електронний(і) кабінет(и) вони доступні? 16.4.2. Електронний кабінет керівника або відповідальної особи (МІС): додати новий функціонал відображення та роботи з переліком неверифікованих працівників (які потребують ручної обробки), змінити існуючі процеси: реєстрації нового медичного працівника, редагування запису реєстру працівників, деактивування запису реєстру працівників? Чи є перелічені процеси вже реалізованими і, якщо так, то через який(і) електронний(і) кабінет(и) вони доступні? 16.4.3. Електронний кабінет працівника НСЗУ ЦБД ЕСОЗ: додати нову функцію (яку ще не було реалізовано): Присвоєння для запису пацієнта ознаки “not_verifired”, якщо запис не був верифікований працівником НСЗУ; в модулі “Пацієнти” змінити існуючу функцію “Деталі пацієнта” (функція вже є реалізованою), змінити процеси, які вже є реалізованими: Редагування запису пацієнта, Об'єднання записів пацієнта (мердж); Роз’єднання записів пацієнта (зворотній мердж); Деактивування запису пацієнта із зазначенням причини. Якщо працівник НСЗУ за результатами верифікації інформації про РНОКПП і паспортних даних пацієнта деактивує запис пацієнта, то реєстраційний запис пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ має бути збагачений такою інформацією: дата деактивації; причина деактивації? ? Чи є перелічені процеси вже реалізованими і, якщо так, то через який(і) електронний(і) кабінет(и) вони доступні? 16.5. Питання: Чи для перелічених електронних кабінетів вже реалізовано сервіс сповіщення користувача після авторизації?
Доброго дня! Відповідно поставлених питань надаємо наступні відповіді.
16. Питання: Чи правильно ми зрозуміли, що:
16.1. Електронний кабінет мед персоналу (МІС), Електронний кабінет керівника або відповідальної особи (МІС) - це існуючі, вже впроваджені електронні кабінети системи МІС?
Відповідь: так
16.2. Електронний кабінет працівника НСЗУ ЦБД ЕСОЗ - існуючий кабінет ЦБД ЕСОЗ?
Відповідь: так
16.3. МІС та ЦБД ЕСОЗ - це різні системи?
Відповідь: так, ЦБД ЕСОЗ - центальний компонент без доступу медичних працівників, Медичні інформаціна система (МІС) - система для роботи медичних працівників. МІС та ЦБД ЕСОЗ обмінуються між собою.
16.4. Перелічені Електронні кабінети потрібно доопрацювати наступним чином:
16.4.1. Електронний кабінет мед персоналу (МІС): додати новий функціонал відображення та роботи з переліком неверифікованих пацієнтів (які потребують ручної обробки), змінити існуючі процеси: реєстрації пацієнта, редагування запису реєстру пацієнтів, об’єднання записів (ідентифікованого пацієнта з неідентифікованим медичними працівниками)? Чи є перелічені процеси вже реалізованими і, якщо так, то через який(і) електронний(і) кабінет(и) вони доступні?
Відповідь: додати функціонал відображення - так, існуючі процесси не потребують змін в кабінетах МІС
16.4.2. Електронний кабінет керівника або відповідальної особи (МІС): додати новий функціонал відображення та роботи з переліком неверифікованих працівників (які потребують ручної обробки), змінити існуючі процеси: реєстрації нового медичного працівника, редагування запису реєстру працівників, деактивування запису реєстру працівників? Чи є перелічені процеси вже реалізованими і, якщо так, то через який(і) електронний(і) кабінет(и) вони доступні?
Відповідь: додати функціонал відображення - так, існуючі процесси не потребують змін в кабінетах МІС
16.4.3. Електронний кабінет працівника НСЗУ ЦБД ЕСОЗ: додати нову функцію (яку ще не було реалізовано): Присвоєння для запису пацієнта ознаки “not_verifired”, якщо запис не був верифікований працівником НСЗУ; в модулі “Пацієнти” змінити існуючу функцію “Деталі пацієнта” (функція вже є реалізованою), змінити процеси, які вже є реалізованими: Редагування запису пацієнта, Об'єднання записів пацієнта (мердж); Роз’єднання записів пацієнта (зворотній мердж); Деактивування запису пацієнта із зазначенням причини. Якщо працівник НСЗУ за результатами верифікації інформації про РНОКПП і паспортних даних пацієнта деактивує запис пацієнта, то реєстраційний запис пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ має бути збагачений такою інформацією: дата деактивації; причина деактивації? ? Чи є перелічені процеси вже реалізованими і, якщо так, то через який(і) електронний(і) кабінет(и) вони доступні?
Відповідь: додати функціонал відображення - так, існуючі процесси не потребують змін в кабінеті НСЗУ
16.5. Питання: Чи для перелічених електронних кабінетів вже реалізовано сервіс сповіщення користувача після авторизації?
Відповідь: ні, потрібно реалізувати
Допуск учасників тендеру до аукціону
37. Питання: Чи оголошення про проведення конкурентної процедури закупівлі оприлюднюється відповідно до норм частини третьої статті 10 Закону? Тобто, чи правильно ми розуміємо, що буде виконано алгоритм: “у день і час закінчення строку подання тендерних пропозицій, зазначених в оголошенні, електронною системою закупівель автоматично розкриваються всі файли тендерної пропозиції, крім інформації про ціну/приведену ціну тендерної пропозиції. Замовник розглядає тендерні пропозиції на відповідність вимогам тендерної документації до проведення оцінки тендерних пропозицій у строк, що не перевищує 20 робочих днів. За результатами розгляду складається та оприлюднюється протокол розгляду всіх тендерних пропозицій. Після оприлюднення Замовником протоколу розгляду тендерних пропозицій електронною системою закупівель автоматично розсилаються повідомлення всім учасникам тендеру та оприлюднюється перелік учасників, тендерні пропозиції яких не відхилені згідно із цим Законом. ”? Чи правильно ми розуміємо, що на допуск учасника тендеру до аукціону не впливає цінова пропозиція цього учасника тендера, сформована відповідно до Додатку 8 до Тендерної документації?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 37. Питання: Чи оголошення про проведення конкурентної процедури закупівлі оприлюднюється відповідно до норм частини третьої статті 10 Закону? Тобто, чи правильно ми розуміємо, що буде виконано алгоритм: “у день і час закінчення строку подання тендерних пропозицій, зазначених в оголошенні, електронною системою закупівель автоматично розкриваються всі файли тендерної пропозиції, крім інформації про ціну/приведену ціну тендерної пропозиції. Замовник розглядає тендерні пропозиції на відповідність вимогам тендерної документації до проведення оцінки тендерних пропозицій у строк, що не перевищує 20 робочих днів. За результатами розгляду складається та оприлюднюється протокол розгляду всіх тендерних пропозицій. Після оприлюднення Замовником протоколу розгляду тендерних пропозицій електронною системою закупівель автоматично розсилаються повідомлення всім учасникам тендеру та оприлюднюється перелік учасників, тендерні пропозиції яких не відхилені згідно із цим Законом. ”? Чи правильно ми розуміємо, що на допуск учасника тендеру до аукціону не впливає цінова пропозиція цього учасника тендера, сформована відповідно до Додатку 8 до Тендерної документації?
Відповідь: Так
Уточнююче запитання до відповіді на питання 1
-1. Питання: Який саме документ та які вимоги до його наповнення має бути наданий учасником тендеру, відповідно до вимоги “Учасники процедури закупівлі повинні надати у складі тендерних пропозицій інформацію та документи, які підтверджують відповідність тендерної пропозиції учасника технічним, якісним, кількісним та іншим вимогам до предмета закупівлі, установленим замовником (згідно Додатку №3 цієї документації).”?__ –-Ваша відповідь: “Згідно пункту 3 Додатку 4 (Перелік документів, які повинні бути завантажені учасником у складі тендерної пропозиції): "3. Інформація та документи про необхідні технічні, якісні та кількісні характеристики предмета закупівлі згідно Додатку 3 до тендерної документації у тому числі: - Згода з умовами та вимогами, які визначені у технічній специфікації (Додатку 3 до тендерної документації) та гарантування їх виконання у вигляді підписаної технічної специфікації або у вигляді окремої довідки-згоди."____________________________ —Уточнююче запитання: Чи повинен/може учасник тендеру подати його версію уточненого ТЗ, сформовану на основі початкового ТЗ та відповідей Замовника на запитання? Чи потрібна саме згода з початковою версією ТЗ, викладеною в початковій тендерній документації?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. -1. Питання: Який саме документ та які вимоги до його наповнення має бути наданий учасником тендеру, відповідно до вимоги “Учасники процедури закупівлі повинні надати у складі тендерних пропозицій інформацію та документи, які підтверджують відповідність тендерної пропозиції учасника технічним, якісним, кількісним та іншим вимогам до предмета закупівлі, установленим замовником (згідно Додатку №3 цієї документації).”?__ –-Ваша відповідь: “Згідно пункту 3 Додатку 4 (Перелік документів, які повинні бути завантажені учасником у складі тендерної пропозиції): "3. Інформація та документи про необхідні технічні, якісні та кількісні характеристики предмета закупівлі згідно Додатку 3 до тендерної документації у тому числі: - Згода з умовами та вимогами, які визначені у технічній специфікації (Додатку 3 до тендерної документації) та гарантування їх виконання у вигляді підписаної технічної специфікації або у вигляді окремої довідки-згоди."____________________________ —Уточнююче запитання: Чи повинен/може учасник тендеру подати його версію уточненого ТЗ, сформовану на основі початкового ТЗ та відповідей Замовника на запитання? Чи потрібна саме згода з початковою версією ТЗ, викладеною в початковій тендерній документації?
Відповідь: Не повинен. Потрібна згода з версією ТЗ, що викладено в тендерній документації
Уточнююче запитання до відповіді на уточнення до 16.4.1 та 17
-Питання: У відповіді на запитання 16.4.1 ви відповіли, що в “Електронний кабінет мед персоналу (МІС):” потрібно “додати функціонал відображення”. У відповіді на запитання 17 ви відповіли, що змінювати кабінет мед. персоналу не потрібно. Як розуміти дані відповіді? Чи вони не суперечать одна одній? _-Ваша відповідь: кабінет МІС розробляють вендори по МІС, зміни в самому кабінеті будуть створені ними, тобто пора рамками даного ТЗ, але метод АРІ потрібен повертати інформацію для відображення статусу.___________ —--- Уточнююче запитання: Тобто в процесах, вказаних в розділах ТЗ 3.2, 3.3, 3.5, 3.6 на схемах 5, 6, 8, 9 всі кроки, вказані в пулах кабінетів МІС (Електронний кабінет медичного працівника, персоналу та Електронний кабінет керівника або відповідальної особи) не входять в поточне ТЗ та не є предметом поточної закупівлі? А також всі вимоги в описах даних процесів типу “лікар отримує сповіщення” та “керівник та/або відповідальна особа отримує сповіщення” обмежуються передачею повідомлення від ЕСОЗ до МІС на бекенді(BE) та не потребують жодної реалізації на FE в рамках поточної закупівлі?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. -Питання: У відповіді на запитання 16.4.1 ви відповіли, що в “Електронний кабінет мед персоналу (МІС):” потрібно “додати функціонал відображення”. У відповіді на запитання 17 ви відповіли, що змінювати кабінет мед. персоналу не потрібно. Як розуміти дані відповіді? Чи вони не суперечать одна одній? _-Ваша відповідь: кабінет МІС розробляють вендори по МІС, зміни в самому кабінеті будуть створені ними, тобто пора рамками даного ТЗ, але метод АРІ потрібен повертати інформацію для відображення статусу.___________ —--- Уточнююче запитання: Тобто в процесах, вказаних в розділах ТЗ 3.2, 3.3, 3.5, 3.6 на схемах 5, 6, 8, 9 всі кроки, вказані в пулах кабінетів МІС (Електронний кабінет медичного працівника, персоналу та Електронний кабінет керівника або відповідальної особи) не входять в поточне ТЗ та не є предметом поточної закупівлі? А також всі вимоги в описах даних процесів типу “лікар отримує сповіщення” та “керівник та/або відповідальна особа отримує сповіщення” обмежуються передачею повідомлення від ЕСОЗ до МІС на бекенді(BE) та не потребують жодної реалізації на FE в рамках поточної закупівлі?
Відповідь: так в поточній закупівлі тільки реалізація на backend
Уточнююче запитання до відповіді на запитання 26.
26. Чи механізм накладання/перевірки КЕП вже реалізований в перелічених Електронних кабінетах і його необхідно перевикористати для вказаних процесів? Чи потрібно реалізовувати новий механізм накладання/перевірки КЕП? Ваша Відповіть: функціонал реалізовано___________ —Уточнююче запитання: Чи правильно ми розуміємо, що механізм накладання/перевірки КЕП вже реалізовано і в Електронному кабінеті працівника НСЗУ ЦБД ЕСОЗ?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 26. Чи механізм накладання/перевірки КЕП вже реалізований в перелічених Електронних кабінетах і його необхідно перевикористати для вказаних процесів? Чи потрібно реалізовувати новий механізм накладання/перевірки КЕП? Ваша Відповіть: функціонал реалізовано___________ —Уточнююче запитання: Чи правильно ми розуміємо, що механізм накладання/перевірки КЕП вже реалізовано і в Електронному кабінеті працівника НСЗУ ЦБД ЕСОЗ?
Відповідь: так
Уточнення ТЗ
7. В документі “ТД (інтеграція з ДФС)”: в розділі “5.9. Вимоги до інформаційного забезпечення” ст. 76 є текст: “ПП повинен мати властивості інтегрованого інформаційного середовища:” “забезпечувати зберігання даних про історію змін даних користувачами Для забезпечення відповідальності за внесення змін до даних;” 7.1. Питання: Перегляд історії повинен забезпечуватись через UI? Чи достатньо можливості перегляду через БД? 7.2. Питання: Чи мається на увазі історія змін даних в таблиці “DRFO_Database”? 7.3. Питання: Чи мається на увазі історія зміни даних в реєстрах пацієнтів та медпрацівників? Якщо так, то чи таке ведення історії змін даних в даних реєстрах не реалізоване вже? 7.4. Питання: Чи не реалізовано вже перегляд історії зміни даних реєстрів в Електронних кабінетах мед персоналу (МІС), керівника або відповідальної особи (МІС), працівника НСЗУ ЦБД ЕСОЗ? “забезпечувати автоматичну консолідацію та інформаційну цілісність у рамках географічно розподілених даних;” 7.5. Питання: Що мається на увазі? Які саме дії повинна виконувати система? “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами” 7.6. Питання: Повинно бути реалізоване окреме АРІ? Якщо так, які саме дані повинні передаватись/отримуватись?
Доброго дня!
Відповідно поставлених питань надаємо наступні відповіді.
7. В документі “ТД (інтеграція з ДФС)”: в розділі “5.9. Вимоги до інформаційного забезпечення” ст. 76 є текст: “ПП повинен мати властивості інтегрованого інформаційного середовища:” “забезпечувати зберігання даних про історію змін даних користувачами Для забезпечення відповідальності за внесення змін до даних;”
7.1. Питання: Перегляд історії повинен забезпечуватись через UI? Чи достатньо можливості перегляду через БД?
ВІдповідь: необхідно доповнити відображення через UI.
7.2. Питання: Чи мається на увазі історія змін даних в таблиці “DRFO_Database”?
Відповідь: так
7.3. Питання: Чи мається на увазі історія зміни даних в реєстрах пацієнтів та медпрацівників? Якщо так, то чи таке ведення історії змін даних в даних реєстрах не реалізоване вже?
Відповідь: так, необхідно доповнити існуючий функціонал ведення історії змін статусами та ознаками джерела інформації
7.4. Питання: Чи не реалізовано вже перегляд історії зміни даних реєстрів в Електронних кабінетах мед персоналу (МІС), керівника або відповідальної особи (МІС), працівника НСЗУ ЦБД ЕСОЗ? “забезпечувати автоматичну консолідацію та інформаційну цілісність у рамках географічно розподілених даних;”
Відповідь: необхідно доповнити існуючий функціонал ведення історії змін статусами та ознаками джерела інформації
7.5. Питання: Що мається на увазі? Які саме дії повинна виконувати система? “передбачати за допомогою документованого API можливість інтеграції з іншими інформаційними системами”
ВІдповідь: ЕСОЗ виступає у ролі ЦБД для обміну з Медичними Інформаційними Системами СГуСОЗ. Результат реалізований функціонал має бути доступний для передачі через існуючі методи АРІ - буде необхідно вносити зміни до методів, що буде визначено при розробці.
7.6. Питання: Повинно бути реалізоване окреме АРІ? Якщо так, які саме дані повинні передаватись/отримуватись?
ВІдповідь: так, дані згідно з наявним у ТЗ описом сервісів “ТРЕМБІТА”
Сервіси перевірки
20. Питання: Коли, за яких умов повинні запускатись сервіси, описані в розділах 3.1.4.1. та 3.1.4.2. ТЗ (в документі “ТД (інтеграція з ДФС)”)? 21. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.4.1. Автоматична верифікація відомостей про фізичну особу в Реєстрі пацієнтів ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО” ст.55: “У разі отримання результату “Незаповнені або некоректно заповнені поля, що обов’язкові для заповнення” (RESULT=3) запису пацієнта в Реєстрі пацієнтів ЕСОЗ присвоюється ознака "auto_not_verifired" і дата, коли така ознака була присвоєна.” - Питання: Чи в реєстрі пацієнтів дані поля (для даної ознаки та дати) вже наявні? Чи потрібно додати нові поля в Реєстр пацієнтів? 22. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.4.1. Автоматична верифікація відомостей про фізичну особу в Реєстрі пацієнтів ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО” “Вимоги до процесу:” ст. 57 “Має бути забезпечена база / таблиця(і) з збереженими результатами верифікації відомостей про пацієнтів в Реєстрі пацієнтів, а медичних працівників в Реєстрі медичних працівників ЦБД ЕСОЗ через забезпечення сумісності та електронної взаємодії з ДРФО на підставі отриманих відомостей з нього, яка може бути використана з метою верифікації даних при роботі з записом пацієнта в електронному кабінеті, побудови додаткових запитів, аналітичної інформації, експорту даних в структурі, що включає реквізити вихідних баз та бази результат.” - Питання: Це має бути таблиця “DRFO_Database” ? Чи інша окрема таблиця? 23. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “4. Вимоги до внесення змін до ЦБД ЕСОЗ”: пункт “2. Після впровадження функціоналу даного документу необхідно скасувати існуючий функціонал валідації ІПН по даті народження та статі, а також пацієнтів, що відмовились від ІПН.” -23.1. Питання: Чи процеси, наведені у розділах 3.2 - 3.6 ТЗ, вже реалізовані та потребують зміни? Чи дані процеси відсутні і їх потрібно реалізувати як нові? -23.2. В яких саме процесах є задіяним і потребуватиме скасування існуючий функціонал валідації ІПН по даті народження та статі, а також пацієнтів, що відмовились від ІПН? 24. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.2. Верифікація відомостей про фізичну особу під час її реєстрації та оновлення даних медичним працівником як пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ щодо валідності РНОКПП відповідно до даних у ДРФО” ст.60 “Вимоги до процесу: Має бути забезпечена база / таблиця(і) зі збереженими результатами кроків процесів реєстрації пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ через забезпечення сумісності та електронної взаємодії з ДРФО на підставі отриманих відомостей з нього, яка може бути використана з метою побудови додаткових запитів, аналітичної інформації, експорту даних в структурі, що включає реквізити вихідних баз та бази результат; ЦБД ЕСОЗ має забезпечувати збереження нового підписного контенту; ЦБД ЕСОЗ має забезпечувати логування дій користувачів.” Аналогічні “Вимоги до процесу:” вказані також в розділах 3.3 - 3.6. - 24.1. Питання: Чи для кожного процесу 3.2 - 3.6 повинна бути реалізована окрема таблиця? Чи такі таблиці є вже реалізованими та потребують зміни, чи такі таблиці потрібно створити? - 24.2. Питання: Чи поточна реалізація ЦБД ЕСОЗ вже забезпечує збереження нового підписного контенту та логування дій користувачів для процесів 3.2 - 3.6 чи їх аналогів?
Доброго дня! Відповідно поставлених питань надаємо наступні відповіді.
20. Питання: Коли, за яких умов повинні запускатись сервіси, описані в розділах 3.1.4.1. та 3.1.4.2. ТЗ (в документі “ТД (інтеграція з ДФС)”)?
Відповідь: 3.1.4.1 для перевірки існуючого РНОКПП в ЕСОЗ, 3.1.4.2 для доповнення запису пацієнта отриманним РНОКПП
21. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.4.1. Автоматична верифікація відомостей про фізичну особу в Реєстрі пацієнтів ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО” ст.55: “У разі отримання результату “Незаповнені або некоректно заповнені поля, що обов’язкові для заповнення” (RESULT=3) запису пацієнта в Реєстрі пацієнтів ЕСОЗ присвоюється ознака "auto_not_verifired" і дата, коли така ознака була присвоєна.” - Питання: Чи в реєстрі пацієнтів дані поля (для даної ознаки та дати) вже наявні? Чи потрібно додати нові поля в Реєстр пацієнтів?
Відповідь: потрібно додати нові
22. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.4.1. Автоматична верифікація відомостей про фізичну особу в Реєстрі пацієнтів ЦБД ЕСОЗ щодо відповідності РНОКПП даним у ДРФО” “Вимоги до процесу:” ст. 57 “Має бути забезпечена база / таблиця(і) з збереженими результатами верифікації відомостей про пацієнтів в Реєстрі пацієнтів, а медичних працівників в Реєстрі медичних працівників ЦБД ЕСОЗ через забезпечення сумісності та електронної взаємодії з ДРФО на підставі отриманих відомостей з нього, яка може бути використана з метою верифікації даних при роботі з записом пацієнта в електронному кабінеті, побудови додаткових запитів, аналітичної інформації, експорту даних в структурі, що включає реквізити вихідних баз та бази результат.” - Питання: Це має бути таблиця “DRFO_Database” ? Чи інша окрема таблиця?
ВІдповідь: таблиця “DRFO_Database”
23. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “4. Вимоги до внесення змін до ЦБД ЕСОЗ”: пункт “2. Після впровадження функціоналу даного документу необхідно скасувати існуючий функціонал валідації ІПН по даті народження та статі, а також пацієнтів, що відмовились від ІПН.” -
23.1. Питання: Чи процеси, наведені у розділах 3.2 - 3.6 ТЗ, вже реалізовані та потребують зміни? Чи дані процеси відсутні і їх потрібно реалізувати як нові? Відповідь: необхідно реалізувти нові
23.2. В яких саме процесах є задіяним і потребуватиме скасування існуючий функціонал валідації ІПН по даті народження та статі, а також пацієнтів, що відмовились від ІПН?
ВІдповідь: у подальших процесах зв’язаних з наданням медичних послуг
24. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.2. Верифікація відомостей про фізичну особу під час її реєстрації та оновлення даних медичним працівником як пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ щодо валідності РНОКПП відповідно до даних у ДРФО” ст.60 “Вимоги до процесу: Має бути забезпечена база / таблиця(і) зі збереженими результатами кроків процесів реєстрації пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ через забезпечення сумісності та електронної взаємодії з ДРФО на підставі отриманих відомостей з нього, яка може бути використана з метою побудови додаткових запитів, аналітичної інформації, експорту даних в структурі, що включає реквізити вихідних баз та бази результат; ЦБД ЕСОЗ має забезпечувати збереження нового підписного контенту; ЦБД ЕСОЗ має забезпечувати логування дій користувачів.” Аналогічні “Вимоги до процесу:” вказані також в розділах 3.3 - 3.6. –
24.1. Питання: Чи для кожного процесу 3.2 - 3.6 повинна бути реалізована окрема таблиця? Чи такі таблиці є вже реалізованими та потребують зміни, чи такі таблиці потрібно створити? –
Відповідь: достатньо однієї таблиці
24.2. Питання: Чи поточна реалізація ЦБД ЕСОЗ вже забезпечує збереження нового підписного контенту та логування дій користувачів для процесів 3.2 - 3.6 чи їх аналогів?
Відповідь: так
Уточнення до відповідей 7.4-7.6
Дякуємо за ваші відповіді. Через відсутність форматування тексту на 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 можливість інтеграції з іншими інформаційними системами” Попереднє питання: Повинно бути реалізоване окреме АРІ? Якщо так, які саме дані повинні передаватись/отримуватись? Ваша відповідь: так, дані згідно з наявним у ТЗ описом сервісів “ТРЕМБІТА” Уточнююче питання: Тобто в даній вимозі маються на увазі тільки сервіси, описані в ТЗ, іншого АРІ реалізовувати не потрібно? І описані в ТЗ сервіси є сервісами системи “ТРЕМБІТА”?
Відповідь - так, тут мова про обмін ЕСОЗ-ТРЕМБІТА, цей обмін необхідно реалізувати.
Інтеграція
8. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52: “Мікросервіс електронного обміну даними повинен забезпечувати: … наявність обов’язкових параметрів для запиту до визначених реєстрів; функціонал отримання даних з різних зовнішніх реєстрів згідно з запитами АРІ; …” - Питання: Будь ласка, уточніть, які саме реєстри маються на увазі під “визначеними” та під “різними зовнішніми”, які саме параметри потрібно отримувати, та згідно з якими запитами АРІ. 9. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52 “У мікросервісі електронного обміну повинні бути реалізовані наступні вимоги: фільтри по сервісах (реєстрах), з яких будуть отримуватись дані; наявність переліку обов'язкових параметрів у запиті для кожного окремого сервісу; наявність переліку допоміжних параметрів у запиті для кожного окремого сервісу; таблицю для стандартизації назв параметрів відповіді для кожного окремого сервісу для співставлення з назвами параметрів ЦБД ЕСОЗ.” - Питання: Чи правильно ми розуміємо, що тут мається на увазі веб сторінки опису параметрів сервісів для відображення користувачу та пошук по даним сторінкам? Чи реалізовані такі сторінки для інших сервісів (реєстрів), якщо мікросервіс електронного обміну вже є реалізованим для інших сервісів (реєстрів)?
Доброго дня! Відповідно поставлених питань надаємо наступні відповіді.
8. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52: “Мікросервіс електронного обміну даними повинен забезпечувати: … наявність обов’язкових параметрів для запиту до визначених реєстрів; функціонал отримання даних з різних зовнішніх реєстрів згідно з запитами АРІ; …”
- Питання: Будь ласка, уточніть, які саме реєстри маються на увазі під “визначеними” та під “різними зовнішніми”, які саме параметри потрібно отримувати, та згідно з якими запитами АРІ.
Відповідь: ДРАЦСГ (Реєстрація смерті), ДФС (реєстр РНОКПП), ДМС (Реєстр документів, що підтверджують особу та реєстр УНЗР). Для кожного з реєстрів існує перелік сервісів ТРЕМБІТА, що описані в окремих ТЗ. В рамках данного ТЗ надано опис сервісів та перелік полів.
9. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами” ст. 52 “У мікросервісі електронного обміну повинні бути реалізовані наступні вимоги: фільтри по сервісах (реєстрах), з яких будуть отримуватись дані; наявність переліку обов'язкових параметрів у запиті для кожного окремого сервісу; наявність переліку допоміжних параметрів у запиті для кожного окремого сервісу; таблицю для стандартизації назв параметрів відповіді для кожного окремого сервісу для співставлення з назвами параметрів ЦБД ЕСОЗ.” - Питання: Чи правильно ми розуміємо, що тут мається на увазі веб сторінки опису параметрів сервісів для відображення користувачу та пошук по даним сторінкам? Чи реалізовані такі сторінки для інших сервісів (реєстрів), якщо мікросервіс електронного обміну вже є реалізованим для інших сервісів (реєстрів)?
Відповідь: мається на увазі доповнення (або створення, якщо дане ТЗ піде в роботу першим) на бекенді мікросервісу, що буде викорстано в рамках обміну з держ реєстрами. Відображення лише результатів обміну у вигляді даних з реєстру чи статусу - кожен випадок описан в ТЗ
Уточнююче питання до відповіді на питання 15.
15. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами”: “Бізнес вимоги:”: ст. 53:_ Схема доступна за посиланням: https://drive.google.com/file/d/1QhVFP71qN4FZn1f5yASsIozcVwB580mp/view?usp=sharing_ _- Питання: Чи правильно ми розуміємо, що функції, вказані в “SCOPE компонентів” на схемі, вже є реалізованими та їх ендпоінти виклику повинні будуть активуватись в рамках відповідних процесів?__ Ваша відповідь: Наразі не реалізовано - необхідно реалізувати в частині обміну з ДФС__ Уточнююче запитання: Тобто не реалізовані механізми реєстрації медичного працівника та реєстрації пацієнта? _-Ваша Відповідь: наразі не реалізовано запит до мікросервісу при реєстрації/оновленні. Самі методи реєстрації/оновлення реалізовані.________ ---Уточнююче запитання нове: Чи правильно ми розуміємо, що також реалізовані самі методи: об’єднання person та preperson пацієнта, деактивація пацієнта, деактивація медичного працівника, перевірка наявності дублюючих запитів пацієнта в реєстрі пацієнта, перевірка наявності дублюючих запитів мед працівника в реєстрі мед працівників?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 15. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.3. Внесення змін до мікросервісу електронного обміну зі сторонніми реєстрами”: “Бізнес вимоги:”: ст. 53:_ Схема доступна за посиланням: https://drive.google.com/file/d/1QhVFP71qN4FZn1f5yASsIozcVwB580mp/view?usp=sharing_ _- Питання: Чи правильно ми розуміємо, що функції, вказані в “SCOPE компонентів” на схемі, вже є реалізованими та їх ендпоінти виклику повинні будуть активуватись в рамках відповідних процесів?__ Ваша відповідь: Наразі не реалізовано - необхідно реалізувати в частині обміну з ДФС__ Уточнююче запитання: Тобто не реалізовані механізми реєстрації медичного працівника та реєстрації пацієнта? _-Ваша Відповідь: наразі не реалізовано запит до мікросервісу при реєстрації/оновленні. Самі методи реєстрації/оновлення реалізовані.________ ---Уточнююче запитання нове: Чи правильно ми розуміємо, що також реалізовані самі методи: об’єднання person та preperson пацієнта, деактивація пацієнта, деактивація медичного працівника, перевірка наявності дублюючих запитів пацієнта в реєстрі пацієнта, перевірка наявності дублюючих запитів мед працівника в реєстрі мед працівників?
Відповідь: об’єднання person та preperson пацієнта, перевірка наявності дублюючих запитів пацієнта в реєстрі пацієнта, перевірка наявності дублюючих запитів мед працівника в реєстрі мед працівників - реалізовано. Деактивація пацієнта, деактивація медичного працівника - реалізовано в ручному режимі, потрібна буде доробка для автоматичної деактивації
Уточнення ТЗ
18. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.2.2. Вимоги до таблиці даних "DRFO_Database"” ст. 49: “Дані таблиці “DRFO_Database” повинні бути доступними для взаємодії (обмін даними) із різними компонентами ЦБД ЕСОЗ” - Питання: Це має бути АРІ на отримання даних? чи взаємодія напряму в БД? 19. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.2.1. Правила форматування масиву даних та стандартизації параметрів масиву даних, який отриманий у результаті електронної взаємодії через СЕВДЕІР із ДРФО” ст.48 “Мікросервіс електронної взаємодії ЦБД ЕСОЗ має забезпечувати: форматування масиву даних, який отриманий у результаті електронної взаємодії із сервісами СЕВДЕІР (ДРФО): “forDRFOCodeChecking”, “FindRegistrationDRFO” та “InfoRNОКPPDRFO”; стандартизацію параметрів масиву даних. Бізнес правила:... 2.Мікросервіс ЦБД ЕСОЗ має забезпечити імпорт стандартизованих даних з сервісів “forDRFOCodeChecking”, “FindRegistrationDRFO” та “InfoRNОКPPDRFO” до таблиці “DRFO_Database” (оновлення/збагачення таблиці) у мікросервісі ЦБД ЕСОЗ. ” - Питання: Чи означає це, що крім таблиці “DRFO_Database” повинна бути окрема таблиця для “сирих даних”, куди повинні зберігатись дані, отримані з перелічених сервісів, до стандартизації цих даних?
Доброго дня! Відповідно поставлених питань надаємо наступні відповіді.
18. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.2.2. Вимоги до таблиці даних "DRFO_Database"” ст. 49: “Дані таблиці “DRFO_Database” повинні бути доступними для взаємодії (обмін даними) із різними компонентами ЦБД ЕСОЗ” - Питання: Це має бути АРІ на отримання даних? чи взаємодія напряму в БД?
Відповідь: взаємодія на рівні БД
19. В документі “ТД (інтеграція з ДФС)”: ТЗ: розділ “3.1.2.1. Правила форматування масиву даних та стандартизації параметрів масиву даних, який отриманий у результаті електронної взаємодії через СЕВДЕІР із ДРФО” ст.48 “Мікросервіс електронної взаємодії ЦБД ЕСОЗ має забезпечувати: форматування масиву даних, який отриманий у результаті електронної взаємодії із сервісами СЕВДЕІР (ДРФО): “forDRFOCodeChecking”, “FindRegistrationDRFO” та “InfoRNОКPPDRFO”; стандартизацію параметрів масиву даних. Бізнес правила:... 2.Мікросервіс ЦБД ЕСОЗ має забезпечити імпорт стандартизованих даних з сервісів “forDRFOCodeChecking”, “FindRegistrationDRFO” та “InfoRNОКPPDRFO” до таблиці “DRFO_Database” (оновлення/збагачення таблиці) у мікросервісі ЦБД ЕСОЗ. ” - Питання: Чи означає це, що крім таблиці “DRFO_Database” повинна бути окрема таблиця для “сирих даних”, куди повинні зберігатись дані, отримані з перелічених сервісів, до стандартизації цих даних?
Відповідь: окрема таблиця для логування результату первинної обробки.
Уточнення до відповіді на питання 23.2
23.2. В яких саме процесах є задіяним і потребуватиме скасування існуючий функціонал валідації ІПН по даті народження та статі, а також пацієнтів, що відмовились від ІПН?_ ВІдповідь: у подальших процесах зв’язаних з наданням медичних послуг__ Уточнююче запитання: Ці подальші процеси не вказані в рамках даного ТЗ? Які саме це процеси?
Доброго дня! Ці процеси за рамками даного ТЗ. Вимога про скасування існуючого функціонала може бути виключена з даного ТЗ на етапі розмітки беклогу, якщо не буде технічної можливості вносити зміни в існуючий функціонал.
Закупівлі
Аукціони
Увійти до системи
Тарифи та оплата
Про систему 