-
Відкриті торги з публікацією англійською мовою
-
Безлотова
-
КЕП
Послуги зі створення нового програмного забезпечення та модифікації існуючого програмного забезпечення з автоматизації процесів верифікації відомостей, що містяться в реєстрах центральної бази даних електронної системи охорони здоров’я з відомостями, що містяться в Державному реєстрі актів цивільного стану громадян (ДРАЦСГ)
Завершена
11 301 250.00
UAH без ПДВ
мін. крок: 1% або 110 000.00 UAH
мін. крок: 1% або 110 000.00 UAH
Період уточнення:
18.01.2022 20:48 - 11.02.2022 00:00
Відповідь надана
ТД (інтеграція з ДРАЦСГ): Мікросервіс обміну
Номер:
f0377b71b03648c4a8ed980838afb6f4
Дата опублікування:
31.01.2022 13:28
Опис:
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. Питання: Для кожної наступної інтеграції потрібно буде реалізувати окрему частину сервісу, яка не входить в предмет закупівлі? Яким чином повинна бути врахована необхідність такої наступної інтеграції в межах поточної закупівлі? З якою метою наведено вимогу про наступні інтеграції?
Відповідь: Так, для кожної наступної інтеграції буде окрема розробка. Мають бути враховані конфігураційні параметри для налаштування вибору реєстру, наприклад.
Дата відповіді:
04.02.2022 23:24
Відповідь надана
Питання щодо вимог по реалізації ІТ рішення
Номер:
be4d3647544f4634b4e41807ae6a2af6
Дата опублікування:
28.01.2022 10:41
Опис:
23. Питання: АЗ - це акт звірки?
Відповідь:
Доброго дня!
Згідно першого рядка, розділу 1, частини 1 (Загальні відомості 1.1. Абревіатури та терміни, що використовуються в технічному завданні) Додатку 3 до тендерної документації:
"АЗ - Актовий запис"
Дата відповіді:
28.01.2022 12:52
Відповідь надана
Питання щодо вимог по реалізації ІТ рішення
Номер:
d1e5bb896f51410c9443e648bfae06a2
Дата опублікування:
27.01.2022 15:35
Опис:
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 Процес реєстрації мед. працівника , накладання підпису КЕП та перевірка валідності - це реалізований функціонал?
Відповідь: Так
Дата відповіді:
01.02.2022 18:35