Верифікація відомостей про пацієнта під час реєстрації пацієнта
28. п. 3.4. Верифікація відомостей про пацієнта під час реєстрації пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ щодо наявності/відсутності інформації про нього в ДРАЦСГ як про особу, яка ідентифікована як померла - Схема 5 - Крок 5.2 «Внутрішні валідації» _-Питання: Які саме валідації проходить запит на реєстрацію пацієнта?
Доброго дня! Внутрішні валідації поза скоупом даної закупівлі. Наприклад відповість номеру документу пацієнта згідно з типом.
Структура файлів WSDL
32. Додаток №2. Структура файлів WSDL для сервісу “GetDeathArByFullNameAndBirthDate” доступно за посиланням _-Питання: не працює перехід за посиланням. Де можна подивитись структуру файлів? 33. Додаток №3. Структура файлів WSDL для сервісу “GetDeathArByComposeDatePeriod” доступно за посиланням _-Питання: не працює перехід за посиланням. Де можна подивитись структуру файлів?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді.
32. Додаток №2. Структура файлів WSDL для сервісу “GetDeathArByFullNameAndBirthDate” доступно за посиланням _-Питання: не працює перехід за посиланням. Де можна подивитись структуру файлів?
Відповідь: посилання GetDeathArByFullNameAndBirthDate - https://directory-prod.trembita.gov.ua:8443/SEVDEIR/GOV/00015622/3_MJU_DRACS_prod/GetDeathArByFullNameAndBirthDate
33. Додаток №3. Структура файлів WSDL для сервісу “GetDeathArByComposeDatePeriod” доступно за посиланням _-Питання: не працює перехід за посиланням. Де можна подивитись структуру файлів?
Відповідь: GetDeathArByComposeDatePeriod - https://directory-prod.trembita.gov.ua:8443/SEVDEIR/GOV/00015622/3_MJU_DRACS_prod/GetDeathArByComposeDatePeriod
Вимоги до внесення змін до ЦБД ЕСОЗ: МРІ
31. п. Вимоги до внесення змін до ЦБД ЕСОЗ 1. В МРІ необхідно реалізувати таблицю (базу) Death_Database для зберігання та оновлення даних від ДРАЦСГ згідно складу відповіді на запит (див. Додаток №1. Опис складу результату вивантаження даних з АЗ про…) для забезпечення процесів викладених у блоці 3. _-Питання: Що таке МРІ?
Доброго дня!
База даних Master Patient Index
Електронна взаємодія через СЕВДЕІР із ДРАЦСГ
25. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація та співставлення отриманих записів із ЦБД ЕСОЗ Схема 1. Перша електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Схема 2. Періодична електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Питання: Які системні помилки та повідомлення повинні виводитись користувачу при отриманні результату з помилкою (крок 1.4, 1.8, 1.10, 1.12; 2.4, 2.8, 2.10, 2.14) - вкажіть будь ласка текст повідомлення помилки? Якому саме з користувачів повинне виводитись повідомлення про помилку та в якому UI?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 25. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація та співставлення отриманих записів із ЦБД ЕСОЗ Схема 1. Перша електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Схема 2. Періодична електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Питання: Які системні помилки та повідомлення повинні виводитись користувачу при отриманні результату з помилкою (крок 1.4, 1.8, 1.10, 1.12; 2.4, 2.8, 2.10, 2.14) - вкажіть будь ласка текст повідомлення помилки? Якому саме з користувачів повинне виводитись повідомлення про помилку та в якому UI?
Відповідь: 1.4 коди та описи помилок вказані на схемі1, аналогічно отриманих у 1.3. 1.8, 1.10, 1.12 - “Пацієнта не може бути визначено” . 2.4 - коди та описи помилок вказані на схемі2, аналогічно отриманих у 2.3. 2.8, 2.10, 1.14 - “Пацієнта не може бути визначено”. Потрібно виводити помилки для працівника НСЗУ, для лікаря не потрібно - лише передавати по АРІ
Електронна взаємодія через СЕВДЕІР із ДРАЦСГ
26. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація та співставлення отриманих записів із ЦБД ЕСОЗ Схема 1. Перша електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Питання: Старт схеми - яка саме системна подія мається на увазі? Чи " Агент періодичних запитів" - це сервіс, який, по заданій через конфіг періодичності, викликає запит?
Доброго дня! Системна подія - ручне ініцюювання обміну через конфігураційний параметр. “Агент періодичних запитів" - так сервіс асихронного обміну з конфігураційним параметром
Електронна взаємодія через СЕВДЕІР із ДРАЦСГ
27. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація та співставлення отриманих записів із ЦБД ЕСОЗ Схема 1. Перша електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Питання: Крок 1 - хто формує перший запит і вказує параметри запиту (чи запит створює автоматично система ЦБД ЕСОЗ чи користувач з роллю «Адміністратора»)? Питання: які параметри запиту вводяться?
Доброго дня! Першу електронну взаємодію ініціює адміністратор. Параметри запиту вказані у Додатку 3
Роль owner. Уточнююче запитання до відповіді на питання 20.
30. Уточнююче запитання до вашої відповіді на питання 20 щодо звільненню співробітника (нижче наведено питання, вашу відповідь та уточнююче питання до вашої відповіді): “1. п. 3.3 “Внесення зміни та/або доповнення до відомостей про медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ щодо реєстрації смерті через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього ” “Схема 4. Верифікація смерті особи за результатами співставлення записів таблиці “Death_Database” з реєстраційними записами медичних працівників у Реєстрі медичних працівників ЦБД ЕСОЗ” _-Питання попереднє: Незрозуміла логіка між кроками 4.13 “Підпис КЕП” та 4.14 “Звільнення працівника” опишіть її? Що означає роль owner? _-Ваша Відповідь: між кроками 4.13 “Підпис КЕП” та 4.14 “Звільнення працівника” вже є реалізований функціонал звільнення співробітника, необхідно його перевикористати. Роль owner - власник/директор СГуСОЗ має право на прийом/звільнення співробітників. _-Уточнююче питання: Чи для ролі owner має бути реалізовано окремий кабінет, в якому відображається реєстр співробітників для звільнення? Як відбувається процес перевірки та звільнення медичного працівника для ролі owner?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді.
30. Уточнююче запитання до вашої відповіді на питання 20 щодо звільненню співробітника (нижче наведено питання, вашу відповідь та уточнююче питання до вашої відповіді): “1. п. 3.3 “Внесення зміни та/або доповнення до відомостей про медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ щодо реєстрації смерті через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього ” “Схема 4. Верифікація смерті особи за результатами співставлення записів таблиці “Death_Database” з реєстраційними записами медичних працівників у Реєстрі медичних працівників ЦБД ЕСОЗ” _-Питання попереднє: Незрозуміла логіка між кроками 4.13 “Підпис КЕП” та 4.14 “Звільнення працівника” опишіть її? Що означає роль owner? _-Ваша Відповідь: між кроками 4.13 “Підпис КЕП” та 4.14 “Звільнення працівника” вже є реалізований функціонал звільнення співробітника, необхідно його перевикористати. Роль owner - власник/директор СГуСОЗ має право на прийом/звільнення співробітників. _-Уточнююче питання: Чи для ролі owner має бути реалізовано окремий кабінет, в якому відображається реєстр співробітників для звільнення? Як відбувається процес перевірки та звільнення медичного працівника для ролі owner?
Відповідь: фрон кабінетів мед працівників поза даної закупівлі, необхідно лише передавати ознаку по АРІ. Аналогічно - система дозволяє двох owner (умовно що має бути звільнено та нового), сповіщати необхідно обох
Питання щодо вимог по реалізації ІТ рішення
23. Питання: АЗ - це акт звірки?
Доброго дня!
Згідно першого рядка, розділу 1, частини 1 (Загальні відомості 1.1. Абревіатури та терміни, що використовуються в технічному завданні) Додатку 3 до тендерної документації:
"АЗ - Актовий запис"
Питання щодо вимог по реалізації ІТ рішення
1. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація та співставлення отриманих записів із ЦБД ЕСОЗ Схема 1. Перша електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Схема 2. Періодична електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ Питання: які системні помилки та повідомлення виводяться користувачу при отриманні результату з помилкою (крок 1.4, 1.8, 1.10, 1.12; 2.4, 2.8, 2.10, 2.14)? Питання: чим відрізняється перша і періодична електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ? Перша електронна взаємодія - одноразовий процес? 2. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація та співставлення отриманих записів із ЦБД ЕСОЗ Схема 3. Верифікація смерті особи за результатами співставлення записів таблиці “Death_Database” з реєстраційними записами пацієнтів в Реєстрі пацієнтів ЦБД ЕСОЗ Питання: які вимоги до розрахунку низького/середнього/високого коефіцієнту порівняння? 3. Питання: чи можете надати повний перелік ролей та їх повноважень? Або підтвердіть запропоновані нами ролі для реалізації: - Роль: Користувач Електронного кабінету НСЗУ. Має доступи: --Доступ до записів пацієнтів в Електронному кабінеті НСЗУ --Робота з Реєстром пацієнтів ЦБД ЕСОЗ в Електронному кабінеті НСЗУ - Роль: Користувач Електронного кабінету медичного працівника/персоналу (МІС). Має доступи: --Доступ до записів пацієнтів в Електронному кабінеті медичного працівника/персоналу (МІС) --Робота з Реєстром пацієнтів ЦБД ЕСОЗ Електронному кабінеті медичного працівника/персоналу (МІС) - Роль: Користувач Електронного кабінету керівника або уповноваженої особи СГуСОЗ. Має доступи: --Доступ до записів медичних працівників в Електронному кабінеті керівника або уповноваженої особи СГуСОЗ --Робота з Реєстром медичних працівників ЦБД ЕСОЗ в Електронному кабінеті керівника або уповноваженої особи СГуСОЗ -Роль: Адміністратор. Має доступи: --Ведення реєстру користувачів та призначення їм ролей в системі ЦБД ЕСОЗ - адміністратор --Права на конфігурацію (активація/деактивація) щодо наданого терміну опрацювання запиту на уточнення щодо ідентифікації медичного працівника, як особи, що померла керівнику та/або уповноваженій особі СГуСОЗ 4. Питання: Чи є повний перелік модулів та підмодулів для кожного електронного кабінета (Електронному кабінеті медичного працівника/персоналу (МІС); Електронному кабінеті керівника або уповноваженої особи СГуСОЗ; Електронному кабінеті НСЗУ)? 5. Питання: “Деактивація реєстраційних записів пацієнтів та медичних працівників, які ідентифіковані як померлі особи в Реєстрі пацієнтів та Реєстрі медичних працівників” та “Присвоєння ознаки “Підтвердження СГуСОЗ”, якщо факт смерті пацієнта підтверджено та накладання КЕП” це одна і та сама процедура чи різні? 6. п. 3.3 “Якщо керівник та/або уповноважена особа СГуСОЗ за результатами опрацювання запиту на уточнення підтверджує ідентифікацію медичного працівника, як особи, що померла, та підтверджує підписом КЕП має відбуватися автоматичний перехід до процесу звільнення медичного працівника. Реєстраційний запис медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ деактивується та змінює статус з “Активний” на “Неактивний” з набуттям стандартних функцій та правил валідацій неактивного запису, зникає в підмодулі “Запити на уточнення”, модуля “Працівники” електронного кабінету керівника та/або уповноваженої особи СГуСОЗ. Процес завершено.” Питання: чи потрібно реалізовувати функціонал звільнення працівника? Питання: при опрацюванні запиту керівником та/або уповноваженою особою СГуСОЗ чи присвоюються ознаки “Підтверджено СГуСОЗ”/“Не підтверджено СГуСОЗ” або використовується лише статус “Активний”/“Неактивний”? 7.Питання: який функціонал має бути допрацьований, а який реалізований з нуля? Чи вірно ми зрозуміли, доопрацювати (перелік верхньорівневий без деталізації необхідного переліку баз/таблиць/перевірок): - Електронний кабінет НСЗУ: --перегляд реєстру пацієнтів та реєстраційного запису пацієнта, таблиці “Death_Database”; --присвоєння ознаки “Підтверджено НСЗУ” або “Не підтверджено НСЗУ” та накладання КЕП. - Електронний кабінет медичного працівника/персоналу (МІС): -- перегляд реєстру пацієнтів та реєстраційного запису пацієнта, таблиці “Death_Database”; -- присвоєння ознаки “Підтверджено СГуСОЗ” або “Не підтверджено СГуСОЗ” та накладання КЕП. - Електронний кабінет керівника або уповноваженої особи СГуСОЗ: -- перегляд реєстру медичних працівників та реєстраційного запису медичного працівника, таблиці “Death_Database”; -- присвоєння ознаки “Підтверджено СГуСОЗ” або “Не підтверджено СГуСОЗ” та накладання КЕП. Реалізувати з 0: - Інтеграція ЦБД ЕСОЗ із системою електронної взаємодії державних електронних інформаційних ресурсів (СЕВДЕІР (“Трембіта”) - Автоматична Верифікація смерті особи за результатами співставлення записів таблиці “Death_Database” з реєстраційними записами пацієнтів в Реєстрі пацієнтів ЦБД ЕСОЗ 8. Питання: чи потрібно реалізовувати новий мікросервіс обміну чи доопрацьовувати існуючий? 9. п. 2.2. Вимоги щодо авторизації користувачів Авторизація користувачів має здійснюватись відповідно до загальних правил та політик авторизації ЦБД ЕСОЗ. Особливих вимог щодо авторизації користувачів в рамках Системи не передбачається. Питання: чи реалізована авторизація та реєстрація користувачів? 10. п. 2.2 Вимоги щодо використання довідників? Питання: надайте перелік назв довідників? 11. Питання: В якому випадку використовуються веб-сервіс “GetDeathArByComposeDatePeriod” (сервіс вивантаження даних АЗ про смерть за період за датою складання АЗ), а в якому “GetDeathArByFullNameAndBirthDate” (сервіс вивантаження даних АЗ про смерть за ПІБ та датою народження)? 12. п. 3.1.3 “Опис процесу верифікації та співставлення записів” Питання: High Weight/Low Weight це коефіцієнт порівняння високий/низький? Питання: “визначення значень граничної ваги співставлення, при досягненні якої пари записів залишаються для розгляду (Low Weight), а також граничної ваги співставлення, при досягненні якої пари записів визнаються такими, що належать одній особі без подальшого розгляду (High Weight). ” - значення граничної ваги співставлення мають налаштовуватись вручну адміністратором на боці Замовника? 13. Питання: Кроки схем 1.11, 2.13, 3.1, 4.1 “Верифікація запису” - це одна і та сама операція? 14. Питання: Верифікація запису здійснюється у кабінетах (Електроннму кабінеті керівника або уповноваженої особи СГуСОЗ, Електронному кабінеті НСЗУ, Електронному кабінеті медичного працівника/персоналу (МІС) чи в кабінет вже потрапляє результат верифікаціі? 15. п. 3.1.2 “перевірка щодо наявності дублюючих записів та їх вилучення” та п. 3.2 “При розрахованому середньому коефіцієнті порівняння або визначених записів “близнюків” такому реєстраційному запису пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ автоматично встановлюється ознака “Ідентифікований як потенційно померлий” Питання: дублі/близнюки вилучати чи встановлювати ознаку “Ідентифікований як потенційно померлий”? 16. Питання: Чи реалізовано процесс звільнення медичного працівника? 17. п. 3.3 “Якщо медичний працівник не звільнений вчасно, необхідно забезпечити дані для перерахунків за договорами по деклараціях (поза межами даного функціоналу). ” Питання: Реалізовувати таблицю з даними? Якщо так вкажіть повний перелік полів таблиці? 18. п. 3.3 “Має бути забезпечена функціональність передачі повідомлень в EventManager щодо деактивації запису медичного працівника. МІС повинен отримати повідомлення від EventManager про деактивацію запису медичного працівника.” Питання: Що таке EventManager? Хто отримає повідомлення від нього? 19. п. 3.3 “Якщо керівником та/або уповноваженою особою СГуСОЗ в термін N днів не забезпечено опрацювання запиту на уточнення щодо ідентифікації медичного працівника, як особи, що померла, то має бути реалізовано сповіщення медичного працівника, при вході в ЦБД ЕСОЗ, про необхідність обробки запиту про уточнення з боку керівника та/або уповноваженої особи протягом Х днів, в іншому випадку обліковий запис медичного працівника може бути деактивовано.” Питання: Сповіщення має надійти до медичного працівника, обліковий запис якого може бути деактивовано? 20. п. 3.3 “Внесення зміни та/або доповнення до відомостей про медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ щодо реєстрації смерті через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього ” Схема 4. Верифікація смерті особи за результатами співставлення записів таблиці “Death_Database” з реєстраційними записами медичних працівників у Реєстрі медичних працівників ЦБД ЕСОЗ Питання: Незрозуміла логіка між кроками 4.13 “Підпис КЕП” та 4.14 “Звільнення працівника” опишіть її? Що означає роль owner? 21. Питання: п. 3.4 Процес реєстрації пацієнта, накладання підпису КЕП та перевірка валідності - це реалізований функціонал? 22. Питання: п. 3.5 Процес реєстрації мед. працівника , накладання підпису КЕП та перевірка валідності - це реалізований функціонал?
Доброго дня!
1. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація ... Питання: які системні помилки та повідомлення виводяться користувачу при отриманні результату з помилкою (крок 1.4, 1.8, 1.10, 1.12; 2.4, 2.8, 2.10, 2.14)? Питання: чим відрізняється перша і періодична електронна взаємодія через СЕВДЕІР та верифікація отриманих запитів в ЦБД ЕСОЗ? Перша електронна взаємодія - одноразовий процес?
Відповідь: Перша взаємодія виконується один раз по всім записам БД, періодична виконується по графіку
2. п. 3.1. Електронна взаємодія через СЕВДЕІР із ДРАЦСГ. Верифікація... Питання: які вимоги до розрахунку низького/середнього/високого коефіцієнту порівняння?
Відповідь: Все є реалізований функціонал онлайн дедудблікації, потрбіно буде його перевикористати
3. Питання: чи можете надати повний перелік ролей та їх повноважень? Або підтвердіть запропоновані нами ролі для реалізації: - Роль: Користувач Електронного кабінету НСЗУ. Має доступи: --Доступ до записів пацієнтів в Електронному кабінеті НСЗУ --Робота з Реєстром пацієнтів ЦБД ЕСОЗ в Електронному кабінеті НСЗУ - Роль: Користувач Електронного кабінету медичного працівника/персоналу (МІС). Має доступи: --Доступ до записів пацієнтів в Електронному кабінеті медичного працівника/персоналу (МІС) --Робота з Реєстром пацієнтів ЦБД ЕСОЗ Електронному кабінеті медичного працівника/персоналу (МІС) - Роль: Користувач Електронного кабінету керівника або уповноваженої особи СГуСОЗ. Має доступи: --Доступ до записів медичних працівників в Електронному кабінеті керівника або уповноваженої особи СГуСОЗ --Робота з Реєстром медичних працівників ЦБД ЕСОЗ в Електронному кабінеті керівника або уповноваженої особи СГуСОЗ -Роль: Адміністратор. Має доступи: --Ведення реєстру користувачів та призначення їм ролей в системі ЦБД ЕСОЗ - адміністратор --Права на конфігурацію (активація/деактивація) щодо наданого терміну опрацювання запиту на уточнення щодо ідентифікації медичного працівника, як особи, що померла керівнику та/або уповноваженій особі СГуСОЗ
Відповідь: Рольова модель існує і може бути передана після підписання угоди, в разі необхідності внесення змін у неї
4. Питання: Чи є повний перелік модулів та підмодулів для кожного електронного кабінета (Електронному кабінеті медичного працівника/персоналу (МІС); Електронному кабінеті керівника або уповноваженої особи СГуСОЗ; Електронному кабінеті НСЗУ)?
Відповідь: Повний перелік передбачає весь функціонал ЕСОЗ - не потрібен в рамках данного ТЗ. Необхідно доповнити функціонал модуля “Пацієнти”
5. Питання: “Деактивація реєстраційних записів пацієнтів та медичних працівників, які ідентифіковані як померлі особи в Реєстрі пацієнтів та Реєстрі медичних працівників” та “Присвоєння ознаки “Підтвердження СГуСОЗ”, якщо факт смерті пацієнта підтверджено та накладання КЕП” це одна і та сама процедура чи різні?
Відповідь: це різні процедури - різні сутності в ЕСОЗ та різні доступи для пацієнта та медичного працівника
6. п. 3.3 “Якщо керівник та/або уповноважена особа СГуСОЗ за результатами ... Процес завершено.” Питання: чи потрібно реалізовувати функціонал звільнення працівника?
Відповідь: функціонал існує
Питання: при опрацюванні запиту керівником та/або уповноваженою особою СГуСОЗ чи присвоюються ознаки “Підтверджено СГуСОЗ”/“Не підтверджено СГуСОЗ” або використовується лише статус “Активний”/“Неактивний”?
Відповідь: І присвоюються ознаки Підтверджено СГуСОЗ”/“Не підтверджено СГуСОЗ і використовується статус
7.Питання: який функціонал має бути допрацьований, а який реалізований з нуля? Чи вірно ми зрозуміли, доопрацювати (перелік верхньорівневий без деталізації необхідного переліку баз/таблиць/перевірок):
- Електронний кабінет НСЗУ:
--перегляд реєстру пацієнтів та реєстраційного запису пацієнта, таблиці “Death_Database”;
Відповідь: перегляд пацієнта реалізовано, таблицію “Death_Database” та відображення інформації з неї необхідно реалізувати
--присвоєння ознаки “Підтверджено НСЗУ” або “Не підтверджено НСЗУ” та накладання КЕП.
Відповідь: необхідно реалізувати
- Електронний кабінет медичного працівника/персоналу (МІС):
-- перегляд реєстру пацієнтів та реєстраційного запису пацієнта, таблиці “Death_Database”;
Відповідь: перегляд пацієнта реалізовано, таблицію “Death_Database” та відображення інформації з неї необхідно реалізувати
-- присвоєння ознаки “Підтверджено СГуСОЗ” або “Не підтверджено СГуСОЗ” та накладання КЕП.
Відповідь: необхідно реалізувати
- Електронний кабінет керівника або уповноваженої особи СГуСОЗ:
-- перегляд реєстру медичних працівників та реєстраційного запису медичного працівника, таблиці “Death_Database”;
Відповідь: перегляд реєстру медичних працівників реалізовано, таблицію “Death_Database” та відображення інформації з неї необхідно реалізувати
-- присвоєння ознаки “Підтверджено СГуСОЗ” або “Не підтверджено СГуСОЗ” та накладання КЕП.
Відповідь: необхідно реалізувати
Реалізувати з 0:
- Інтеграція ЦБД ЕСОЗ із системою електронної взаємодії державних електронних інформаційних ресурсів (СЕВДЕІР (“Трембіта”)
Відповідь: необхідно реалізувати
- Автоматична Верифікація смерті особи за результатами співставлення записів таблиці “Death_Database” з реєстраційними записами пацієнтів в Реєстрі пацієнтів ЦБД ЕСОЗ
Відповідь: необхідно реалізувати
8. Питання: чи потрібно реалізовувати новий мікросервіс обміну чи доопрацьовувати існуючий?
Відповідь: необхідно реалізувати новий
9. п. 2.2. Вимоги щодо авторизації користувачів ... в рамках Системи не передбачається. Питання: чи реалізована авторизація та реєстрація користувачів?
Відповідь: реалізовано
10. п. 2.2 Вимоги щодо використання довідників? Питання: надайте перелік назв довідників?
Відповідь: перелік буде надано при розмітці беклога проекту
11. Питання: В якому випадку використовуються веб-сервіс “GetDeathArByComposeDatePeriod” (сервіс вивантаження даних АЗ про смерть за період за датою складання АЗ), а в якому “GetDeathArByFullNameAndBirthDate” (сервіс вивантаження даних АЗ про смерть за ПІБ та датою народження)?
Відповідь:“GetDeathArByComposeDatePeriod” використовується при першому на при періодичному автоматичному обміні; “GetDeathArByFullNameAndBirthDate” - при ручному запиті з кабінету НСЗУ
12. п. 3.1.3 “Опис процесу верифікації ... без подальшого розгляду (High Weight). ” - значення граничної ваги співставлення мають налаштовуватись вручну адміністратором на боці Замовника?
Відповідь: так
13. Питання: Кроки схем 1.11, 2.13, 3.1, 4.1 “Верифікація запису” - це одна і та сама операція?
Відповідь: так
14. Питання: Верифікація запису здійснюється у кабінетах (Електроннму кабінеті керівника або уповноваженої особи СГуСОЗ, Електронному кабінеті НСЗУ, Електронному кабінеті медичного працівника/персоналу (МІС) чи в кабінет вже потрапляє результат верифікаціі?
Відповідь: до кабінетів потрапляє інформація з результатам обміну, правцівник в кабінеті має вручну верифікувати отриману інформацію
15. п. 3.1.2 “перевірка щодо наявності ... ознака “Ідентифікований як потенційно померлий” Питання: дублі/близнюки вилучати чи встановлювати ознаку “Ідентифікований як потенційно померлий”?
Відповідь: встановлювати ознаку “Ідентифікований як потенційно померлий”
16. Питання: Чи реалізовано процесс звільнення медичного працівника?
Відповідь: Так
17. п. 3.3 “Якщо медичний працівник не звільнений вчасно, необхідно забезпечити дані для перерахунків за договорами по деклараціях (поза межами даного функціоналу). ” Питання: Реалізовувати таблицю з даними? Якщо так вкажіть повний перелік полів таблиці?
Відповідь: так, необхідно реалізувати нову таблицю. Повний перелік полів буде уточнено на етапі розмітки беклогу
18. п. 3.3 “Має бути забезпечена функціональність передачі повідомлень в EventManager щодо деактивації запису медичного працівника. МІС повинен отримати повідомлення від EventManager про деактивацію запису медичного працівника.” Питання: Що таке EventManager? Хто отримає повідомлення від нього?
Відповідь: Система відправки СМС. Повідомлення отримують медичні працівники
19. п. 3.3 “Якщо керівником та/або уповноваженою особою СГуСОЗ в термін N днів не забезпечено опрацювання запиту на уточнення щодо ідентифікації медичного працівника, як особи, що померла, то має бути реалізовано сповіщення медичного працівника, при вході в ЦБД ЕСОЗ, про необхідність обробки запиту про уточнення з боку керівника та/або уповноваженої особи протягом Х днів, в іншому випадку обліковий запис медичного працівника може бути деактивовано.” Питання: Сповіщення має надійти до медичного працівника, обліковий запис якого може бути деактивовано?
Відповідь: так
20. п. 3.3 “Внесення зміни та/або доповнення до відомостей про медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ щодо реєстрації смерті через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього ” Схема 4. Верифікація смерті особи за результатами співставлення записів таблиці “Death_Database” з реєстраційними записами медичних працівників у Реєстрі медичних працівників ЦБД ЕСОЗ Питання: Незрозуміла логіка між кроками 4.13 “Підпис КЕП” та 4.14 “Звільнення працівника” опишіть її? Що означає роль owner?
Відповідь: між кроками 4.13 “Підпис КЕП” та 4.14 “Звільнення працівника” вже є реалізований функціонал звільнення співробітника, необхідно його перевикористати. Роль owner - власник/директор СГуСОЗ має право на прийом/звільнення співробітників.
21. Питання: п. 3.4 Процес реєстрації пацієнта, накладання підпису КЕП та перевірка валідності - це реалізований функціонал?
Відповідь: Так
22. Питання: п. 3.5 Процес реєстрації мед. працівника , накладання підпису КЕП та перевірка валідності - це реалізований функціонал?
Відповідь: Так
ТД (інтеграція з ДРАЦСГ): Мікросервіс обміну
24. ТД (інтеграція з ДРАЦСГ): “3.1.4 Створення мікросервісу обміну зі сторонніми реєстрами” “Також необхідно передбачити можливість електронного обміну з іншими сервісами “ТРЕМБІТА” для отримання даних інших реєстрів, а саме Державний реєстр фізичних осіб (сервіси forDRFOCodeChecking, FindRegistrationDRFO); Єдиний демографічний реєстр; Єдиний реєстр засуджених та осіб, взятих під варту. Кожна наступна інтеграція з сервісами “ТРЕМБІТА” буде здійснюватись лише через мікросервіс електронного обміну. При кожній наступній інтеграції в мікросервіс електронного обміну буде доповнено можливість вибору нового реєстру для отримання даних.” 24.1. Питання: Чи це той мікросервіс, який повинен бути доопрацьований в рамках тендеру ДФС https://prozorro.gov.ua/tender/UA-2022-01-17-008863-a ? 24.2. Питання: “Державний реєстр фізичних осіб (сервіси forDRFOCodeChecking, FindRegistrationDRFO)” - хіба ця інтеграція не замовлена в рамках тендеру ДФС? 24.3. Питання: Для кожної наступної інтеграції потрібно буде реалізувати окрему частину сервісу, яка не входить в предмет закупівлі? Яким чином повинна бути врахована необхідність такої наступної інтеграції в межах поточної закупівлі? З якою метою наведено вимогу про наступні інтеграції?
Доброго дня! Відповідно до зазначеного переліку запитань, надаємо наступні відповіді. 24. ТД (інтеграція з ДРАЦСГ): “3.1.4 Створення мікросервісу обміну зі сторонніми реєстрами” “Також необхідно передбачити можливість електронного обміну з іншими сервісами “ТРЕМБІТА” для отримання даних інших реєстрів, а саме Державний реєстр фізичних осіб (сервіси forDRFOCodeChecking, FindRegistrationDRFO); Єдиний демографічний реєстр; Єдиний реєстр засуджених та осіб, взятих під варту. Кожна наступна інтеграція з сервісами “ТРЕМБІТА” буде здійснюватись лише через мікросервіс електронного обміну. При кожній наступній інтеграції в мікросервіс електронного обміну буде доповнено можливість вибору нового реєстру для отримання даних.” 24.1. Питання: Чи це той мікросервіс, який повинен бути доопрацьований в рамках тендеру ДФС https://prozorro.gov.ua/tender/UA-2022-01-17-008863-a ?
Відповідь: Так це той самий мікросервіс.
24.2. Питання: “Державний реєстр фізичних осіб (сервіси forDRFOCodeChecking, FindRegistrationDRFO)” - хіба ця інтеграція не замовлена в рамках тендеру ДФС? 24.3. Питання: Для кожної наступної інтеграції потрібно буде реалізувати окрему частину сервісу, яка не входить в предмет закупівлі? Яким чином повинна бути врахована необхідність такої наступної інтеграції в межах поточної закупівлі? З якою метою наведено вимогу про наступні інтеграції?
Відповідь: Так, для кожної наступної інтеграції буде окрема розробка. Мають бути враховані конфігураційні параметри для налаштування вибору реєстру, наприклад.
Уточнююче питання до відповіді на питання 10.
Уточнююче питання до відповіді на питання 10. 10. п. 2.2 Вимоги щодо використання довідників? Питання: надайте перелік назв довідників? -Ваша Відповідь: перелік буде надано при розмітці беклога проекту____ -Уточнююче питання: Скільки нових довідників потрібно буде створити, скільки з них однорівневих, скільки багаторівневих? Чи потрібно буде реалізовувати CRUD (створення, редагування, оновлення, перегляд запису) для записів нових довідників на UI? Яким чином повинні оновлюватись нові довідники? Дані потрібні для оцінки замовлення.
Доброго дня! Створити довідники “Джерело валідації” (1 рівень), “Зв’язок реєстру та поліів пацієнта/мед працівника” (1 рівень). Інтерфейс для заповнення не потрібен. Оновлення довідників буде відбуватись за рахунок завантаження / прямого запису в БД
Відображення реєстру автоматично деактивованих записів пацієнтів
34. П. 3.2. Внесення зміни та/або доповнення до відомостей про реєстрацію смерті пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього «При автоматичній деактивації реєстраційного запису пацієнта в Реєстрі пацієнтів ЦБД ЕСОЗ по причині ідентифікації пацієнта, як померлої особи, цей запис має бути збагачений інформацією: ● дата деактивації; ● дата смерті (при наявності цієї інформації); ● ID актового запису в ДРАЦСГ; ● причина деактивації. Зазначені параметри мають бути доступними для перегляду в електронних кабінетах медичного працівника та працівника НСЗУ у яких є відповідні права доступу.» _-Питання: в якому модулі-підмодулі електронних кабінетів медичного працівника та працівника НСЗУ відображається реєстр автоматично деактивованих записів пацієнтів, описаний в П. 3.2.?
Доброго дня! Для кабінету працівника НСЗУ необхідно доповнити функціонал модулю Пацієнти. Реалізовувати кабінет медичного працівника не потрібно - потрібно реалізувати таблицю та метод АРІ для відправки інформації ЕСОЗ→МІС
Сповіщення
29. п. 3.3. Внесення зміни та/або доповнення до відомостей про медичного працівника в Реєстрі медичних працівників ЦБД ЕСОЗ щодо реєстрації смерті через забезпечення сумісності та електронної взаємодії з ДРАЦСГ на підставі отриманих відомостей з нього «Якщо керівником та/або уповноваженою особою СГуСОЗ в термін N днів не забезпечено опрацювання запиту на уточнення щодо ідентифікації медичного працівника, як особи, що померла, то має бути реалізовано сповіщення медичного працівника, при вході в ЦБД ЕСОЗ, про необхідність обробки запиту про уточнення з боку керівника та/або уповноваженої особи протягом Х днів, в іншому випадку обліковий запис медичного працівника може бути деактивовано.» _-Питання: Кому з медичних працівників повинне надходити сповіщення? Чи сповіщення повинне відображатись в особистому кабінеті медичного працівника, чиї дані потребують перевірки? Чи сповіщення повинне надходити Керівнику або уповноваженій особі СГуСОЗ в особистий кабінет?
Доброго дня! Медичного працівника аккаунт якого може бути заблоковано. В даній закупівлі необхідно лише передавати по АРІ ознаку, фронт буде реалізовано поза даної закупівлі
