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

1. Зберігання та ведення даних щодо новонароджених;
2. Оформлення та видача довідок про народження дитини;
3. Зберігання та ведення персональних даних щодо матері та батька дитини;
4. Зберігання та ведення даних щодо померлих;
5. Оформлення та видача довідок про смерть;
6. Видача необхідної інформації щодо новонароджених, померлих у вигляді реєстру;
7. Пошук за реєстром інформації щодо новонароджених та померлих.

Основними цілями створення ІАС “СНДІ” є:

1. Впровадження сучасного інформаційно-комунікаційного середовища для створення та ведення нормативно-довідкової інформації;
2. Створення сучасного програмного середовища для інформаційної підтримки діяльності закладів охорони здоров’я та роботи працівників Київського міського інформаційно-обчислювального центру департаменту охорони здоров’я міста Києва;
3. Забезпечення користувачів системи механізмом формування та відображення статистичних даних відповідно до електронних форм;
4. Формування даних, які будуть використовуватись як першоджерело для внесення змін в інші реєстри громади міста Києва.

Об’єктами автоматизації Системи є: 1)                Зберігання, ведення, редагування і відображення інформації щодо померлих та новонароджених осіб; 2)                Відновлення інформації, що міститься в Системі; 3)                Можливість друку сформованих документів; 4)                Зберігання сканованих копій документів; 5)                Ведення класифікаторів, словників; 6)                Адміністрування системи; 7)                Захист Системи від несанкціонованого доступу.

Експлуатація програмно-апаратної платформи з відкритими інтерфейсами  обміну даними для надання електронних послуг повинна виконуватися в умовах, що забезпечують їх нормальне функціонування, згідно з вимогами виробника програмного та технічного забезпечення та діючими нормативними актами. Експлуатація Системи повинна виконуватися за наступними принципами: Технічне супроводження виконується обслуговуючим персоналом Замовника або Виконавця згідно з вимогами виробника програмного та технічного забезпечення, які надаються Виконавцем у вигляді інструкцій з експлуатації; Технічне обслуговування та ремонт виконується персоналом Виконавця відповідно до вимог виробників. Технічне супроводження програмного забезпечення Системи виконується системними адміністраторами, технічне супроводження обладнання Системи виконується технічними спеціалістами Замовника чи Виконавця. Регламент обслуговування обладнання, кількість і кваліфікація обслуговуючого персоналу конкретного робочого місця повинні відповідати вимогам виробника програмно-технічних засобів і бути узгодженим із Замовником. Приміщення, призначені для експлуатації Системи, мають бути обладнані індивідуальним контуром заземлення. Нормальними умовами експлуатації Системи повинні бути: температура навколишнього повітря: +20±5 С°; відносна вологість повітря: 60±15 %; атмосферний тиск: 630-800 мм. рт. ст.

Рис. 1. Верхньорівнева схема побудови рішення Створення ІАС “СНДІ” повинно виконуватись із використанням принципів концепції Free and Open Source Software (FOSS і включає такі вимоги): 1)                Націленість на підвищення швидкості надання послуг  та прискорення процедури видачі документів; 2)                На презентаційному рівні ІАС “СНДІ” являє собою  Веб-інтерфейс для управління вмістом бази даних у відповідності з вимогами за протоколом http; 3)                Мінімальні вимоги до кваліфікації користувачів і необхідності їх навчання; 4)                Забезпечення необхідного рівня конфіденційності персональних даних громадян згідно із Законодавством України; 5)                Резервування компонентів програмного забезпечення ІАС “СНДІ”; 6)                Всі компоненти, що впроваджуватимуться та поставлятимуться в рамках цієї закупівлі мають бути надані на умовах ліцензування GPL (http://www.gnu.org/licenses/gpl.html) і забезпечувати відкритість, прозорість та доступність вихідних кодів продукту за ідеологією OpenSource (ліцензія на вільне програмне забезпечення); 7)                 Сховище даних базується на сервері баз даних PostgreSQL. 8)                  Адаптивне рішення передбачатиме розробку та поставку базових функціонально необхідних елементів дизайну сторінок відповідно до інформаційної архітектури веб-рішення. 9)                 Пропонується створення під систему такого домену: medical.kievcity.gov.ua та організація довіри до нього із організацією відповідного захисту інформації, яка передаватиметься, за рахунок встановлення цифрового розширеного  TLS сертифікату 3го рівня на 3 роки.

До складу рішення входять: 1)                інформаційні ресурси, представлені у вигляді баз даних, в яких зберігаються дані про об’єкти та зв’язки між ними; 2)                набір програмних модулів, які забезпечують введення, обробку, пошук і зберігання необхідної інформації; 3)                інтерфейс, що забезпечує взаємодію користувача з системою в зручній для нього формі; 4)                рольова модель.

Система має забезпечувати можливість виконання наступних функцій згідно з модулями системи: 1)                Модуль з  реєстрації новонароджених в закладах охорони здоров’я. a)      Можливість введення та редагування  персональних даних, стану здоров’я щодо жінки, що народжує. b)     Можливість введення та редагування  персональних даних щодо чоловіка, батька дитини. c)      Можливість введення та редагування  персональних даних, стану здоров’я щодо немовлят. d)     Можливість пошуку по базі необхідної інформації, щодо новонароджених, за великою кількістю критеріїв. e)      Можливість формування та друк необхідних довідок.
f)      Зберігання взаємопов’язаних даних (сканованих копій документів). 2)                Модуль з реєстрації померлих в закладах охорони здоров’я. a)      Можливість введення та редагування  даних щодо померлого, обставин його смерті. b)     Можливість пошуку по базі необхідної інформації, щодо померлих, за великою кількістю критеріїв. c)      Можливість формування та друк необхідних довідок. 3)                Модуль Адміністрування (керування доступом) a)      Централізована система ідентифікації.

1. Управління режимом формування набору необхідних даних щодо користувача.

b)     Робота за протоколами централізованої схеми автентифікації та авторизації. c)      Оновлення ІАС “СНДІ”. d)     Аудит дій користувачів. e)      Ведення журналу безпеки. f)      Ведення технічного журналу роботи. g)     Ведення довідників. 4)                Можливість обміну даними з іншими базами даних. 5)                Модуль зі статистики даних a)      Формування та відображення статистики по введеним даним. b)     Формування звітів із можливістю їх друку.

Рішення, щодо кількості персоналу, Замовник приймає самостійно в залежності від навантаження та необхідності. Вимоги до персоналу ІАС “СНДІ”: 1)                Адміністратор – відповідає за функціонування програмно-технічного комплексу та належне функціонування комплексної системи захисту інформації та входить до складу служби захисту інформації акредитованого центру; 2)                Адміністратор БП – відповідає за наповнення довідників системи та ведення даних по персоналу; 3)                Кінцевий користувач.
Вимоги до кваліфікації персоналу, порядку його підготовки та контролю знань та навичок: 1)                Адміністратори мають мати вищу профільну освіту, або сертифікати про закінчення курсів, пов’язаних з адмініструванням баз даних, захистом інформації; 2)                Кінцеві користувачі, мають мати мінімальну кваліфікацію для роботи з системою.

ІАС “СНДІ” має забезпечувати: 1)                Обслуговувати одночасну роботу до 3000 користувачів; 2)                Швидкість обробки запитів та відображення інформації на сторінці – не більше ніж 5 сек; 3)                Можливість зберігання історичних даних на протязі не менш ніж 20 років; 4)                Первісне завантаження будь-якої веб-сторінки – не більше 4 сек.

Експлуатація системи повинна передбачати наступні режими функціонування: 1)                Основний режим – є режим штатного функціонування всіх компонентів  за своїм призначенням; 2)                Режим адміністрування – є режим здійснення централізованого автоматизованого налагоджування та автоматизованого оновлення СНДІ одночасно з роботою решти користувачів  в основному режимі, або в режимі Технічного обслуговування; 3)                Режим технічного обслуговування – є режим регламентного технічного обслуговування та відновлення працездатності технічних засобів компонентів.

Надійність системи повинна бути забезпечена за  наступними напрямками: 1)                забезпечення працездатності компонентів програмно-технічної платформи; 2)                збереження даних. Збереження працездатності повинно забезпечувати надійність роботи ІАС “СНДІ” при відмові одного або декількох компонентів за рахунок їх резервування. При цьому повинна вимагатися мінімальна увага з боку адміністратора рішення, щодо реакції на усунення наслідків відмов. Збереження даних повинно забезпечуватись програмно-апаратними засобами та механізмами обміну інформацію. Збереження даних  повинно забезпечувати цілісність даних при програмно-апаратних збоях, відмовах, помилках, шляхом використання відповідних програмно-апаратних засобів та рішень, резервного копіювання, транзакційності при змінах даних. Збереження даних має забезпечуватися у випадках: 1)                вимкнення живлення; 2)                відмови технічних засобів обробки інформації; 3)                помилки, збоїв  або руйнування програмного забезпечення; 4)                тимчасової відмови ліній зв’язку. Надійність функціонування системи повинна забезпечуватися: 1)                використанням сучасних технологій розробки  прикладного програмного забезпечення та забезпеченням якісного його тестування; 2)                резервуванням  основних компонентів та елементів системи; 3)                регламентом організації резервного копіювання та архівного збереження інформації в системі; 4)                обраним способом та регламентом технічного супроводження експлуатації системи; 5)                оперативністю заміни програмно-технічних засобів, що вийшли з ладу; 6)                сумісністю технічних засобів та програмного забезпечення.
Для серверної частини системи повинна бути реалізована одна з наступних стратегій забезпечення надійності: 1)       гаряче резервування, у відповідності до якої дублюючі компоненти знаходяться у режимі “гарячого” резерву. У разі відсутності відклику основного компонента здійснюється автоматичний перехід на застосування резервного компонента; 2)       циклічне переключення компонентів, у відповідності до якої кожний виклик передається компонентам по циклу. У разі відсутності відклику компонента, якому був направлений виклик, здійснюється перехід на використання іншого компоненту.

ІАС “СНДІ” має бути побудована на сервісно-орієнтованій  архітектурі модульного типу, побудованій на сучасних технологіях та у відповідності до міжнародних стандартів. В основі повинна бути архітектура багатоарендності (Multitenancy) із забезпеченням функціонування рішення одночасно із декількома конфігураціями та наборами даних від декількох організацій, в архітектурі яких кожна організація-клієнт працює зі своїм екземпляром  віртуального рішення, маючи доступ тільки до своєї конфігурації та свого набору даних. ІАС “СНДІ” повинна забезпечувати наступні варіанти розгортання:

1. “Розподілене рішення” – коли філії чи відділення організації із різними територіальними розташуваннями можуть працювати в системі в рамках своєї організації (рольової моделі) без будь-яких функціональних обмежень.

ІАС “СНДІ” повинна забезпечувати наступну логічну архітектуру:

1. Використання сучасної бази даних;
2. Має підтримуватись SaaS архітектура.

Клієнтська частина має бути основана на SPA архітектурі та мати адаптивний дизайн інтерфейсу із набором із набором інтерактивних застосувань для персональних комп’ютерів користувачів. Архітектура є комплексним веб-рішенням, що забезпечує роботу із визначеними даними на робочих місцях користувачів через використання веб-браузера та відповідних веб-технологій та інтернет засобів. У разі відсутності Інтернет-з’єднання користувачі системи будуть мати можливість введення інформації в офлайн режимі із застосуванням споріднених програмних засобів, таких як, наприклад, засоби Microsoft Office із подальшим завантаженням інформації у систему. (Даний функціонал може бути реалізований у рамках наступних етапів). Сервер застосувань має бути реалізований з використанням сучасних технологій, таких як AngularJs, Express.JS та NodeJS і т.і.. Клієнтська частина має бути повнофункціональним веб-рішенням, мати зручний сучасний та функціональний веб-дизайн з метою ефективного використання на різних кінцевих користувацьких пристроях за допомогою веб браузерів та надавати таке: 1)                Забезпечення автентифікації/авторизації користувачів за допомогою логіну/паролю згідно до ролевої моделі (такий режим буде використовуватись на етапі тестової експлуатації); 2)                З’єднання з клієнтами за захищеним протоколом HTTPS; 3)                Можливість регулювання навантаження за рахунок масштабування рішення; 4)                Забезпечення надійним механізмом зберігання даних; 5)                Забезпеченням механізмом ідентифікації через ЕЦП.
Рішення для звітів повинно включати в себе: 1)                 Засіб розробки, редагування, ведення і формування звітів та їх публікації для перегляду або роздруку. 2)                Сервіс, який дозволятиме створювати звіти для інтерактивного аналізу даних.

Проектні рішення щодо створення вузлів Системи повинні передбачати заходи та процедури по експлуатації, які узгоджуються з вимогами документа “Про затвердження Правил охорони праці під час експлуатації електронно-обчислювальних машин”, затверджених наказом Державного комітету України з промислової безпеки, охорони праці та гірничого нагляду від 26.03.2010 № 65. Вимоги з техніки безпеки повинні бути відображені в експлуатаційних документах та забезпечувати безпеку при монтажі, налагодженні, експлуатації і ремонті технічних засобів ІАС “СНДІ”. Технічні засоби не повинні створювати шуми та вібрації, електромагнітні поля надвисоких частот, жорсткі та іонізуючі випромінювання, рівні яких перевищують допустимі норми, що встановлені в ГОСТ 12.1.003-83. Граничні рівні шуму у приміщеннях, де працює персонал структурних підрозділів служб, повинні відповідати ГОСТ 27818-88 “Машини обчислювальні та системи оброблення даних. Допустимі рівні шуму на робочих місцях і  методи їх визначення”. Монітори АРМів повинні мати рівень електромагнітного випромінювання відповідно до існуючих санітарних норм. Приміщення, у яких розміщуються технічні засоби, повинні бути обладнані протипожежною сигналізацією, дозволеного до використання в органах державної влади. Загальні вимоги електричної і механічної безпеки мають бути забезпечені відповідно до ГОСТ 12.2.007.0-75 і ГОСТ 25861-83. Засоби захисту людини від ураження електричним струмом повинні відповідати вимогам ГОСТ 12.1.019-75 і ГОСТ 25861-83. Елементи технічних комплексів ІАС “СНДІ” щодо засобів захисту людини від поразки електричним струмом повинні відповідати вимогам ГОСТ 12.2.007.0-75 і ГОСТ 25861-83. Заземлення технічних засобів повинно бути виконано відповідно до вимог ГОСТ 12.2.007.0-75 і ГОСТ 25861-83. Під час монтажу, наладки, експлуатації і ремонту технічних засобів ІАС “СНДІ” повинні виконуватись усі вимоги правил техніки безпеки та правил встановлення та експлуатації електрообладнання.

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

Рішення щодо ергономіки системи повинні відповідати вимогам технічної естетики та інженерної психології для забезпечення гармонійного зв'язку між параметрами технічних засобів і психофізичними можливостями людини із врахуванням створення єдиного об'ємно-просторового і кольорового рішення відповідно до ГОСТ 12.2.032 – 78, ГОСТ 12.2.033 – 78, ГОСТ 24750 – 81. Рішення щодо ергономіки системи повинні забезпечувати: 1)                прості інтуїтивно-зрозумілі інтерфейси, які не потребують тривалого навчання роботі з ними; 2)                форми відображення інформації користувачам, що функціонально орієнтовані на вирішення конкретних задач; 3)                мінімальну кількість дій користувача при виконанні завдань в системі, відсутність в екранних формах функціональних можливостей, що не потрібні для виконання завдання, яке поставлене перед користувачем; 4)                вбудовані механізми валідації значень, що визначаються для окремих полів, комбінацій полів (контекстно-залежний контроль), контроль значень полів за довідниками/класифікаторами, а також на відповідність вже введеним даним (базі даних), валідація буде проводитіся як на фронтовой частині програмного комплексу, так і на серверній, що дозволить контролювати коректність вводу та цілісність даних на всіх етапах обробки їх введення; 5)                вбудовані механізми допомоги внесення та отримання інформації, контекстні підказки.

Експлуатація ІАС “СНДІ” повинна виконуватися в умовах, що забезпечують її нормальне функціонування згідно з вимогами виробників програмного і технічного забезпечення та діючими нормативними документами. Експлуатація Системи повинна виконуватися за наступними принципами: ▪ технічний супровід та технічна підтримка вузлів ІАС “СНДІ”  виконуються технічним персоналом Замовника та/або спеціалістами Виконавця згідно з вимогами виробників обладнання та програмного забезпечення, які надаються Виконавцем у вигляді інструкцій з експлуатації; ▪ склад та регламент робіт з технічного супроводу та підтримки ІАС “СНДІ”, кількість і кваліфікація технічного персоналу повинні відповідати вимогам виробників програмно-технічних засобів і бути узгодженими з Замовником; ▪ проведення робіт з профілактики і ремонту окремих компонентів та блоків ІАС “СНДІ” не повинно порушувати роботу всієї Системи; ▪ технічний та фізичний захист та збереженість апаратних компонентів ІАС “СНДІ” та носіїв даних, безперебійне електропостачання, резервування ресурсів, поточне обслуговування реалізується технічними та організаційними засобами, передбаченими в структурі Замовника; ▪ електроживлення технічних засобів ІАС “СНДІ” повинно здійснюватися від електромережі змінного струму напругою 220 В з частотою
50 Гц; ▪  приміщення, в яких експлуатуватиметься серверне обладнання, повинні відповідати вимогам виробників обладнання щодо розміру площі, необхідної для розміщення апаратури, та наявності системи кондиціювання повітря; ▪ приміщення, де розміщується обладнання ІАС “СНДІ” мають бути обладнані індивідуальним контуром заземлення; ▪ нормальними умовами для експлуатації АРМ користувачів повинні бути: - температура навколишнього повітря: +20±5 С°; - атмосферний тиск: 630-800 мм.рт.ст.; - відносна вологість повітря: 60±15 %.

Вимоги із забезпечення захисту інформації повинні бути реалізовані за рахунок створення комплексної системи захисту інформації (КСЗІ) з використанням комплексу засобів захисту. Для забезпечення обчислення значення електронного цифрового підпису від даних, що записуються до бази даних ІАС “СНДІ”, конфіденційності та цілісності даних, що передаються між сервером застосувань та АРМ користувачів, двофакторної ідентифікації користувачів АРМ, повинен застосовуватися програмний засіб криптографічного захисту інформації, що забезпечуватиме використання механізмів електронного цифрового підпису та відповідатиме наступним загальним вимогам: 1)     мати позитивний експертний висновок Державної служби спеціального зв’язку та захисту інформації України за результатами державної експертизи в сфері криптографічного захисту інформації щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації України; 2)     забезпечити виконання функцій обчислення електронного цифрового підпису даних, шифрування та дешифрування даних, генерації ключових даних (формування криптографічних ключів – особистих ключів та відповідних їм відкритих), формування запитів на сертифікацію відкритого ключа в акредитованому центрі сертифікації ключів; 3)     функціонувати у якості окремої та незалежної частини у складі ІАС “СНДІ” з визначеним переліком функцій; 4)     мати можливість бути використаним у складі інформаційної системи, яка реалізована у якості портального рішення; 5)     повинен реалізувати наступні механізми:

1. контроль цілісності програмного забезпечення;
2. тестування на правильність функціонування та блокування роботи в разі виявлення порушень;
3. захист від порушення конфіденційності інформації внаслідок помилкових дій користувача або в разі відхилень у роботі складових елементів засобу;
4. захист ключових даних на їх носіях від несанкціонованого зчитування;
5. захист засобу від здійснення порушником навмисного зовнішнього впливу;
6. захисту від порушення конфіденційності та цілісності ключових даних на ключових документах.

6)     повинен реалізувати наступні криптографічні алгоритми:

1. алгоритм шифрування даних відповідно до ДСТУ ГОСТ 28147:2009 у режимі гамування із зворотнім зв’язком;
2. алгоритм шифрування даних з контролем цілісності відповідно до ДСТУ ГОСТ 28147:2009 у режимі імітовставки для розподілу ключових даних;
3. алгоритм гешування даних відповідно до ГОСТ 34.311-95;
4. алгоритм обчислення та перевірки електронного цифрового підпису, використання еліптичних кривих, генерація псевдовипадкових послідовностей, генерація ключових даних, перевірка правильності генерації ключових даних, а також обчислювальні процедури в поліноміальному базисі відповідно до ДСТУ 4145-2002.

7)     повинен реалізувати наступні формати, структури, протоколи, алгоритми:

1. позначки часу відповідно до вимог RFC 3161 “Internet X.509 PublicKeyInfrastructure Time-Stamp Protoсol (TSP)” та вимог до протоколу фіксування часу, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1402/21714;
2. інтерактивного визначення статусу сертифіката відповідно до вимог RFC 2560 “Internet X.509 PublicKeyInfrastructureOnlineCertificateStatusProtocol – OCSP” та вимог до протоколу визначення статусу сертифіката, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1403/21715;
3. списку відкликаних сертифікатів відповідно до вимог RFC 5280 “Internet X.509 PublicKeyInfrastructureCertificateandCertificateRevocationList (CRL) Profile” та вимог до формату списку відкликаних сертифікатів, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1400/21712;
4. об’єктні ідентифікатори для криптоалгоритмів, що є державними стандартами відповідно до вимог до структури об’єктних ідентифікаторів для криптоалгоритмів, що є державними стандартами, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 № 1399/21711;
5. запиту на формування сертифіката відкритого ключа, що створюються та обробляються об’єктом експертизи, відповідають вимогам (PKCS#10) CertificationRequestSyntaxSpecification;
6. криптографічних повідомлень, що створюються та обробляються об’єктом експертизи, відповідають вимогам RFC 5652 “CryptographicMessageSyntax (CMS)”, вимогам до формату підписаних даних, що затверджені наказом Мін’юсту, Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 № 1401/21713, вимогам до формату криптографічних повідомлень, що затверджені наказом Адміністрації Держспецзв’язку 18.12.2012 № 739, зареєстровані в Мін’юсті 14.01.2013 за № 108/22640;
7. посиленого сертифіката відкритого ключа, що відповідає вимогам до формату посиленого сертифіката відкритого ключа, що затверджені наказом Мін’юсту та Адміністрації Держспецзв’язку від 20.08.2012 № 1236/5/453 та зареєстровані в Мін’юсті 20.08.2012 за № 1398/21710;
8. формування ключів, шифрування ключів на основі парольної інформації та захисту особистих ключів електронного цифрового підпису та особистих ключів шифрування відповідає вимогам RFC 5208 “Private-Key InformationSyntaxSpecification (PKCS#8)”, RFC 2898 “Password-Based CryptographySpecification (PKCS#5)”, PKCS#12 “PersonalInformation Exchange Syntax”.

8)     Для забезпечення конфіденційності та цілісності даних при введенні даних з клієнтських АРМ, захищеного збереження інформації про дії користувачів та адміністраторів системи повинен застосовуватися програмний засіб криптографічного захисту інформації, що відповідає наступним загальним вимогам:

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

                                                              i.      створення та використання шифрованих файлових контейнерів (шифрованих віртуальних дисків);                                                            ii.      створення шифрованих контейнерів без файлової системи або з файловою системою NTFS чи FAT;                                                          iii.      можливість створення динамічних шифрованих файлових контейнерів;                                                          iv.      створення шифрованого носія на основі переносного жорсткого диску, флеш-накопичувача;                                                             v.      можливість шифрування логічних дисків (томів) жорсткого диску комп’ютера, переносного жорсткого диску, флеш-накопичувача;

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

                                                              i.      алгоритм шифрування даних відповідно до ДСТУ ГОСТ 28147:2009 у режимі гамування із зворотнім зв’язком;                                                            ii.      алгоритм шифрування даних з контролем цілісності відповідно до ДСТУ ГОСТ 28147:2009 у режимі імітовставки для розподілу ключових даних;                                                          iii.      алгоритм гешування даних відповідно до ГОСТ 34.311-95;                                                          iv.      алгоритм перевірки електронного цифрового підпису в поліноміальному базисі відповідно до ДСТУ 4145-2002.

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

Для забезпечення захисту інформації, що передається між основним та резервним центром обробки даних, що розміщуються на територіально-рознесених майданчиках, повинен застосовуватися програмний засіб криптографічного захисту інформації, що відповідає наступним вимогам: 1)     мати дійсний експертний висновок Державної служби спеціального зв’язку та захисту інформації України щодо відповідності вимогам нормативних документів системи криптографічного захисту інформації; 2)     реалізовувати наступні функції:

1. захист трафіку на рівні аутентифікації/шифрування мережевих пакетів по протоколах IPsec AH та/або IPsec ESP;
2. пакетну фільтрацію трафіку з використанням інформації в полях заголовків мережевого і транспортного рівнів;
3. контекстну фільтрацію для протоколів TCP і FTP;
4. класифікацію та маркування трафіку;
5. реалізацію заданого протоколу взаємодії (автентифікацію та/або захист трафіку) для кожного захищеного з’єднання, доступ в заданому захищеному режимі тільки для зареєстрованих партнерів по взаємодії;
6. регульовану стійкість захисту трафіку;
7. підтримка NAT TraversalEncapsulation;
8. маскування топології сегмента мережі, що захищається (тунелювання трафіку);
9. підтримку списку відкликаних сертифікатів (CRL – CertificateRevocationList);
10. реєстрація подій;
11. надання статистики із використанням протоколів SNMP v.1, v.2c;
12. дистанційне та локальне налаштування (за допомогою командної строки або із використанням графічного інтерфейсу);
13. підтримка сервісів QoS.

3)     використовувати алгоритм шифрування ДСТУ ГОСТ 28147:2009 у режимі гамування зі зворотнім зв’язком; 4)     забезпечувати пропускну здатність у режимі шифрування для пакетів UDP та ТСР– не менш 1600 Мбіт/сек. На стадії розробки системи необхідно впровадити технічне рішення з криптографічного захисту інформації відповідно до норм чинного законодавства України:

• для забезпечення конфіденційності та цілісності даних, що передаються між сервером застосувань та АРМ користувачів, повинен застосовуватися програмний засіб криптографічного захисту інформації – “Крипто Автограф” (експертний висновок №05-02-02/819 від 29.02.2016 р.);
• для забезпечення конфіденційності та цілісності даних при введенні даних з клієнтських АРМ, а також захищеного збереження інформації про дії користувачів та адміністраторів системи “Криптософт Storage” (експертний висновок №05-02-02/2246 від 23.06.2014 р.).

ІАС “СНДІ”  має включати програмні засоби діагностики та механізми документування аварійних подій чи помилок. В разі виникнення аварійних подій чи помилок в роботі ІАС “СНДІ”, помилка повинна реєструватися у відповідному електронному журналі, а користувач та/або адміністратор має отримати відповідне повідомлення із зазначенням типу помилки. При цьому має бути реалізована можливість отримання технічної довідкової інформації-допомоги з різним рівнем деталізації, щодо ліквідації аварійних  подій, чи  виправлення помилки. До складу повідомлення щодо події аварійного типу повинні входити: 1)                час; 2)                текстова назва аварії; 3)                назва файлу вихідних текстів; 4)                номер рядка в файлі; 5)                причина помилки.
Також, в разі можливості, повинна передаватись назва функції, яка викликала збій і список відповідних викликів. Всі типи повідомлень повинні бути доступними адміністратору ІАС “СНДІ”. Користувачі порталу в разі виникнення помилок повинні бачити лише скорочені інформаційні повідомлення зрозумілого характеру без технічної деталізації із рекомендаціями щодо подальших дій.

Патентна чистота ІАС “СНДІ” має бути забезпечена розробником і повинна гарантуватися фірмами виробниками програмних засобів. Ліцензійна чистота ІАС “СНДІ” повинна бути забезпечена використанням ліцензійних програмних продуктів та гарантуватися відповідними документами фірм, що їх виробляють. Для розроблюваних компонентів програмного забезпечення ліцензійна чистота має забезпечуватися відповідно до чинного законодавства. В окремих випадках до складу системного та загальносистемного програмного забезпечення ІАС “СНДІ” може бути включено вільно розповсюджувані програмні продукти.

Стандартизація та уніфікація функцій модулів ІАС “СНДІ”  повинна бути забезпечена за рахунок використання сучасних інструментальних програмних засобів які підтримують єдину технологію проектування та розробки функціонального, інформаційного та програмного забезпечень. Рішення з технічного та загального програмного забезпечень модулів ІАС “СНДІ”  повинні передбачати вибір сумісних, найбільш інтегрованих програмних та технічних засобів, які відповідають вимогам сучасних міжнародних стандартів відкритих систем та програмних засобів. У процесі розробки модулів Системи повинні бути сформовані вимоги до розробки прикладного програмного забезпечення, які уніфікують інтерфейс користувача, процедуру обробки інформації, ідентифікацію програмних модулів та баз даних, типізують окремі програмні модулі відповідно до свого призначення.

ІАС “СНДІ”  має складатися з модулів, що наведені на 










Рис. 2. При цьому кожний модуль має відповідати вимогам наведеним у п. 4.1.2. , у даному пункті зазначено загальні вимоги до системи.













Рис. 2. Очікувані модулі системи

Система має складатися з наступних модулів: 1)     Адміністрування – модуль Адміністрування, що складається з додаткових компонентів.

1. Довідники – ведення довідників та інформації щодо державних установ;
2. Управління групами та ролями – управління групами та ролями користувачів;
3. Безпека – виконує автентифікацію та авторизацію користувача, аудит дій користувачів, ведення журналу безпеки, ведення технічного журналу роботи.
4. API Services – для взаємодії із зовнішніми системами та Модулями в межах платформи.

2)     Клієнтський модуль – модуль для роботи працівників державних установ, що включає в себе компоненти:

1. Картка особи – модуль з введення персональної інформації щодо осіб, яким буде видано документ;
2. Реєстрація народження особи – модуль з введення та відображення інформації щодо народження дитини;
3. Реєстрація смерті  особи – модуль з введення та відображення інформації щодо смерті особи;
4. d.     Статистика даних – модуль з формування та відображення статистики по введеним даним. Формування звітів із можливістю  іх друку.

Модуль забезпечує ведення різноманітних довідників у Системі та інформації щодо державних установ. Довідники ведуться в рамках ІАС “СНДІ”. Дані в довідниках мають постійно оновлюватися згідно з відповідною роллю. Довідник вулиць по м. Києву, заповнюються через відповідний АРІ, із зовнішнього джерела з подальшим збереженням в системі відповідних даних, для уникнення випадків зміни вулиці в уже виданих документах. По іншим містам вводиться вручну. Посилання на відповідні сутності в межах веб-інтерфейсу на веб-сторінці повинні бути реалізовані у вигляді прямих посилань. Довідники, що використовуються в ІАС “СНДІ”   і є її невід’ємною частиною: 1)                Довідник типу вулиць; 2)                Довідник типу населених пунктів; 3)                Довідник статі; 4)                Довідник місця смерті; 5)                Довідник причин смерті; 6)                Довідник підстав встановлення смерті; 7)                Довідник виду пологів; 8)                Довідник ознак доношеності; 9)                Довідник виду шлюбу; 10)            Довідник інших суттєвих станів; 11)            Довідник причин смерті дитини; 12)            Довідник статусу пологів; 13)            Довідник типів документів; 14)            Довідник посад лікарів, що прийняли пологи; 15)            Довідник ознаки адреси; 16)            Довідник виду документа; 17)            Довідник країн світу; 18)            Довідник населених пунктів; 19)            Довідник посад лікарів; 20)            Довідник часу настання смерті дитини; 21)            Довідник ким встановлена смерть; 22)            Довідник вулиць.
Інтерфейс взаємодії з Системою – веб-сервіси.
Адміністратор БП має можливість: 1)                завести, відредагувати, вилучити інформацію щодо лікаря; 2)                редагувати список назв закладів охорони здоров’я та встановлювати зв’язки відповідно до бізнес-логіки. 3)                редагувати довідники, що безпосередньо пов’язані з документами. Таблиця 2. Функції управління довідниками

В системі реалізуються функції управління групами та ролями користувачів. Передбачається можливість створення таких ролей: 1)                Працівник ДОЗ; 2)                Лікар; 3)                Адміністратор системи. 4)                Адміністратор БП. Вимоги до Рольової моделі подані нижче. Користувачам надаються права доступу до інформаційних ресурсів з використанням ролей. Прикладні функції “Управління групами та ролями”: 1)     Створення ролі; 2)     Додавання редагування груп користувачів; 3)     Додавання, вилучення користувачів до груп; 4)     Налаштування нотифікацій – Користувач має можливість налаштувати нотифікації по подіям; 5)     Надання прав користувачу або групі користувачів – у межах наданих прав доступу (наприклад, “адміністратор”) Користувач має можливість надавати права іншим користувачам. Таблиця 3. Функції управління “Управління групами та ролями”

Для доступу до захищених ресурсів, користувач повинен пройти процес автентифікації та авторизації. Відповідно до його ролі та належності до групи йому буде надано доступ до відповідного функціоналу модулю. Реалізація передбачатиме такі варіанти роботи із системою: 1. Користувачі мають пройти автентифікацію через використання логіну/паролю (такий режим, буде використовуватись на етапі тестової експлуатації).             або 2. Користувачі мають пройти автентифікацію та/або ідентифікацію через ЕЦП, у випадках коли технологічно буде потрібний  підвищений рівень ідентифікації користувача (із використанням механізмів рольової моделі) та додаткових рівнів автентифікації. Інтерфейс взаємодії з користувачами – веб-сторінки, які є частиною Системи. Таблиця 4. Прикладні функції “Безпека”

Таблиця 5. Функції управління “Безпека”

Модуль забезпечує введення, зберігання, редагування, пошук, перегляд інформації щодо  осіб яким, чи на яких, видається документ. Таблиця 6. Функціональність картки особи

\\ Функція повинна забезпечувати можливість пошуку інформації про особу згідно до реквізитів та отриманням релевантних результатів пошуку на сторінці із розбиттям на визначену кількість результаів в межах однієї сторніки. Введення користувачем пошукових значень реквізитів повинно здійснюватися вручну по таким параметрам:\\ 

Модуль забезпечує введення, зберігання, редагування, пошук, перегляд медичної  інформації щодо  народжених. Таблиця 7.Функціональність інформації про народження

\\ Функція повинна забезпечувати можливість пошуку інформації про особу, по набору реквізитів. Введення користувачем пошукових значень реквізитів повинен здійснюватися вручну по таким параметрам:\\ 

Модуль забезпечує введення, зберігання, редагування, пошук, перегляд медичної  інформації щодо  померлих. Таблиця 8.Функціональність інформації про смерть

\\ Функція повинна забезпечувати можливість пошуку інформації про особу, по набору реквізитів. Введення користувачем пошукових значень реквізитів повинен здійснюватися вручну по таким параметрам:\\ 

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

Інформаційне забезпечення повинно гарантувати: 1)                багаторазове використання даних у різних ділових процесах; 2)                забезпечення  фізичної та логічної цілісності даних; 3)                мінімізацію надмірності даних, що зберігаються; 4)                стандартизацію представлення даних; 5)                достовірність та актуальність даних. 6)                розмежування доступу до даних, запобігання несанкціонованого доступу до них. Інформаційне забезпечення повинно відповідати основним вимогам: 1)                забезпечувати копіювання і зберігання масивів інформації; 2)                забезпечувати мінімізацію обсягу даних, що вводяться вручну; 3)                забезпечувати можливість розширення масивів інформації з урахуванням перспектив розвитку системи. Інформаційне забезпечення  системи повинно включати: 1)                систему класифікації і кодування; 2)                програмні модулі забезпечення інформаційного обміну між компонентами системи та між внутрішніми і зовнішніми інформаційними системами, з якими повинний бути організований обмін. Система класифікації і кодування повинна підтримувати процес накопичення і зберігання інформації, а також вирішення функціональних задач з мінімальними витратами пам‘яті і максимальною швидкодією за рахунок використання класифікаторів таких рівнів: 1)                локальних в межах системи; 2)                відомчих; 3)                загальнодержавних.

Лінгвістичне забезпечення ІАС “СНДІ” повинно включати розвинуті мовні засоби програмування програмного забезпечення та інтерфейсу користувача. Мовні засоби програмування повинні бути обрано Виконавцем відповідно до рішень з програмного забезпечення ІАС “СНДІ”. Інтерфейс користувача повинен бути розроблений українською мовою та забезпечувати: 1)                очевидність кожної дії  на робочих місцях користувачів та введення-виведення інформації на професійно - орієнтованій мові, яка використовує поняття конкретної предметної області ділових процесів; 2)                наявність ефективної допомоги при можливих діях користувача; 3)                максимальне використання при введенні інформації довідників можливих значень даних; 4)                попередження помилкових ситуацій.

 Програмне забезпечення (ПЗ) СНДІ повинне складатися із: 1)                загальносистемного програмного забезпечення (ЗПЗ); 2)                прикладного програмного забезпечення (ППЗ). Програмне забезпечення ІАС “СНДІ” повинно відображати специфіку функціональних задач користувачів та забезпечувати: 1)                підтримку загально прийнятих сучасних міжнародних стандартів до відкритих систем; 2)                сумісність та інтегрованість; 3)                підтримку функціонування в різнорідному апаратному і програмному середовищах; 4)                вмонтованість механізму захисту від помилок і підтримки цілісності. До загальносистемного програмного забезпечення відносяться: 1)                операційні системи; 2)                система управління базами даних (СКБД); 3)                офісні застосування; 4)                антивірусні програмні засоби; 5)                серверні додатки; 6)                тощо. Загальносистемне програмне забезпечення не є предметом даної закупівлі або розробки. Рішення зі складу загальносистемного програмного забезпечення повинні бути технічно та економічно обґрунтовані з точку зору цілісності та обґрунтованої повноти програмного застосування ІАС “СНДІ” його компонентів за призначенням та мінімізації витрат на подальший супровід. До прикладного програмного забезпечення повинно відноситись програмне забезпечення, що розробляється  та налаштовується під час створення ІАС “СНДІ”. За результатами створення та впровадження ІАС “СНДІ”  програмний код прикладного програмного забезпечення повинен бути переданий Виконавцем Замовнику в електронному вигляді. Розробка прикладного програмного забезпечення повинна проводитись за допомогою сучасних інструментальних засобів програмної інженерії проектування і генерації розподілених баз даних (CASE-засобів). При розробці ППЗ повинні використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей ІАС “СНДІ”  за рахунок створення, впровадження та тиражування функціонально завершених програмних модулів.

Специфікація обчислювальної техніки та апаратних засобів мережевої взаємодії повинна забезпечити поетапну реалізацію функціональних задач системи і враховувати: 1)     наявність існуючих технічних засобів у Замовника; 2)     тенденції розвитку обчислювальної техніки та апаратних засобів зв’язку; 3)     можливість фізичного поєднання різнотипової техніки у єдиний програмно-технічний комплекс; 4)     необхідність  взаємодії з зовнішніми автоматизованими системами; 5)     високу пропускну здатність, надійність і безпечність передачі даних. Автоматизовані робочі місця користувачів системи повинні бути розгорнуті на базі сучасних комп’ютерів, технічні характеристики яких враховують функціональне використання автоматизованого робочого місця за призначенням, в повному обсязі, відповідно до вимог щодо якості та регламентів функціонування відповідного модулю (задачі). Мінімальні вимоги до апаратно-технічного забезпечення:

1. Сервер баз даних у кількості 2:
   1. Процесор – 4core min 2.0 Gz;
   2. Оперативний запам'ятовуючий пристрій - Не менше ніж 16 GB;
   3. Дискова підсистема – System: 100Gb, Swap 16Gb, Data: 200Gb;
   4. Операційна система – CentOS 7 64-bit или Ubuntu 16.0.4 LTS 64-bit;
   5. Тип плаформи бази даних – PostgreSQL.

1. Сервер додатків у кількості 2:
   1. Процесор – 4core min 2.0 Gz;
   2. Оперативний запам'ятовуючий пристрій – не менше ніж 16 GB;
   3. Дискова підсистема – System: 100Gb, Swap 16Gb, Data: 200Gb;
   4. Операційна система – CentOS 7 64-bit или Ubuntu 16.0.4 LTS 64-bit.

1. Web Сервер у кількості 2:
   1. Процесор – 4core min 2.0 Gz;
   2. Оперативний запам'ятовуючий пристрій – не менше ніж 8 GB;
   3. Дискова підсистема – System: 100Gb, Swap 16Gb, Data: 200Gb;
   4. Операційна система – CentOS 7 64-bit или Ubuntu 16.0.4 LTS 64-bit.

1. Технічні засоби для роботи працівників охорони здоров’я та  працівників Київського міського інформаційно-обчислювального центру департаменту охорони здоров’я міста Києва.
2. Лазерний принтер.
3. Пристрої записування/читання на CD і DVD.
4. Технічні засоби комунікаційної мережі (включаючи лінії зв’язку).

Вимог до метрологічної сумісності технічних засобів Системи не пред’являється. Якісні характеристики Системи перевіряються на випробуваннях згідно з Програмою і методикою випробувань. На вимогу Замовника метрологічна сумісність технічних засобів може бути проведена сторонніми організаціями.

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

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

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

Інтерфейс ІАС “СНДІ” для користувача включає в себе функціонал згідно
 з Рис. 3:
Рис. 3. Інформаційна архітектура робочого вікна Користувача 1)     Картка особи – відповідає за внесення інформації щодо особи, місця її постійного проживання та інших атрибутів, які пов’язані з особою. 2)     Реєстр документів – відповідає за пошук та відображення на інтерфейсі користувача документів, щодо народжених та померлих, відповідно до прав доступу; 3)     Видача нового документа – відповідає за видачу нового документа замість втраченого чи попереднього; 4)     Формування документа  – відповідає за формування документів безпосередньо пов’язаних з народженням чи смертю особи: 5)     Редагування довідників – відповідає за додавання нових значень, редагування та вилучення значень з довідника; 6)     Редагування працівників – відповідає за додавання нового лікаря, зміну інформації щодо посади, вилучення лікаря, зміну інформації щодо закладу в якому працює лікар. 7)     Статистика – відповідає за формування та відображення статистики по введеним даним, а також за формування звітів з можливістю їх друку.
      Реалізація візуалізації інтерфейсу для користувачів та адміністраторів може відрізнятися від наведеного на Рис. 3 та визначається і узгоджується із Замовником на етапі розробки системи.

Пошук документів має відбуватися по всіх параметрах, які до нього відносяться. Необхідним є створення строки пошуку по всіх параметрах, з додатковою можливістю вибору додаткових показників(обмежень пошуку). 1)                Додаткові показники для пошуку: 2)                Номер документа: з ___до ___; 3)                Дата документа: з ___до ___; 4)                Тип документа; 5)                Орган, що видав документ; 6)                Лікар, що видав документ; 7)                ПІБ особи; 8)                Дата народження; 9)                Дата смерті. При видачі результатів, необхідним є відображення всіх довідок в статусі “Діючий”, “Дублікат”. При відображенні інформації по документам смерті необхідно, щоб документи зі статусом “Попереднє”, “Замість   попереднього”, “Остаточне”, “Замість остаточного” були видимі всім користувачам. Документи зі статусом “Замість   попереднього”, “Остаточне”, “Замість остаточного”, що видаються при пошуку, мають бути доступними для перегляду в друкованій формі всім користувачам, а документи зі статусом “Попереднє”, “Замість   попереднього”, “Остаточне”, “Замість остаточного” мають бути доступними   тільки для закладу, що їх видавав. Поля реєстру, які має видавати система після здійснення пошуку: 1)                Номер документа; 2)                Дата документа; 3)                Тип документа; 4)                Орган, що видав документ; 5)                Лікар, що видав документ; 6)                ПІБ особи.

Процес заведення нової особи має відбуватися згідно Рис. 4.
Рис. 4. Схема процесу заведення “Картки особи” У Таблиця 9 наведено основні атрибути форми, для заведення нової особи чи редагування існуючої. Таблиця 9.Заведення “Картки особи”

*Неідентифікована – поля стають необов’язковими для заповнення. Заведення картки особи має бути динамічним, з картки особи має бути можливість переходу на формування документа. Картка особи має включати в себе функціонал згідно Таблиця 10 . Таблиця 10. Опис стандартних функцій “Картки особи”

До даної функції входить частина функціональності інтерфейсу по сутності “Картка особи”. При переході з сутності “Картка особи” має видавати інформацію щодо “Формування документа”. У формі формування документа має бути передбачено пошук по ключовим параметрам. Наприклад, при внесенні реєстраційного номеру облікової картки платника податків мають підтягнутися данні по особі. ІАС “СНДІ” має видавати форму для заповнення в залежності від обраного документа.

Інформація, яка має автоматично підтягнутися до форми, при переході з “Картка особи” та бути доступною для пошуку, у випадку  “Формування документа”. 1)     Персональна інформація

1. ПІБ матері – критерій для пошуку по БД
2. Стать
3. Сімейний статус
4. Країна проживання

2)     Ідентифікаційна інформація

1. Серія та номер паспорта матері – критерій для пошуку по БД
2. Реєстраційний номер облікової картки платника податків (матері)– критерій для пошуку по БД

3)     Постійне місце проживання

1. Адреса постійного місця проживання – критерій для пошуку по БД

4)     Чорнобильське посвідчення*

1. Наявність чорнобильського посвідчення у матері – ТАК/НІ

                                                              i.      Серія посвідчення                                                            ii.      Номер посвідчення

1. Наявність чорнобильського посвідчення у чоловіка – ТАК/НІ

                                                              i.      Серія посвідчення                                                            ii.      Номер посвідчення Де, * (у разі відсутності інформація по серії та номеру не виводити, виводити “не постраждав”). ВАЖЛИВО: По всім даним, які вже наявні в системі, має бути інформаційне повідомлення, щодо їх перевірки. Повідомлення може бути одним по всім параметрам з подальшим їх виділенням іншим кольором. Процес видачі документа “Медичне свідоцтво про народження” та “Медична довідка  про перебування дитини під наглядом лікувального закладу” має проходити згідно схеми, яка наведена на Рис. 5.
Рис. 5. Схема процесу видачі  документа “Медичне свідоцтво про народження”
В Таблиця 11 описані загальні вимоги щодо документа “Медичне свідоцтво про народження”. Таблиця 11. Формування документа “Медичне свідоцтво про народження”

Інформація, яка має автоматично підтягнутися до форми, при переході з “Картка особи” та бути доступною для пошуку, у випадку  “Формування документа”. 1)     Персональна інформація:

1. ПІБ матері – критерій для пошуку по БД
2. Стать
3. Сімейний статус

2)     Ідентифікаційна інформація:

1. Серія та номер паспорта матері – критерій для пошуку по БД
2. Реєстраційний номер облікової картки платника податків (матері)– критерій для пошуку по БД

3)     Постійне місце проживання:

1. Адреса постійного місця проживання – критерій для пошуку по БД

ВАЖЛИВО: По всім даним, які вже наявні в системі, має бути інформаційне повідомлення, щодо їх перевірки. Повідомлення може бути одним по всім параметрам з подальшим їх виділенням іншим кольором.
В Таблиця 12 описані загальні вимоги, щодо документа “Медична довідка  про перебування дитини під наглядом лікувального закладу”. Таблиця 12.Формування документа “Медична довідка  про перебування дитини під наглядом лікувального закладу”

Інформація, яка має автоматично підтягнутися до форми, при переході з “Картка особи” та бути доступною для пошуку, у випадку  “Формування документа”. 1)     Персональна інформація:

1. ПІБ померлого – критерій для пошуку по БД
2. ПІБ матері померлого – критерій для пошуку по БД (у випадку смерті дитини)
3. Дата народження
4. Стать

2)     Ідентифікаційна інформація:

1. Серія та номер паспорта померлого – критерій для пошуку по БД
2. Реєстраційний номер облікової картки платника податків (померлого) – критерій для пошуку по БД

3)     Постійне місце проживання:

1. Адреса постійного місця проживання – критерій для пошуку по БД

4)     Чорнобильське посвідчення:*

1. Наявність чорнобильського посвідчення у померлого – ТАК/НІ

                                                                          i.            Серія посвідчення                                                                        ii.            Номер посвідчення Де, * (у разі відсутності інформація по серії та номеру не виводити, виводити “не постраждав”).
ВАЖЛИВО: По всім даним, які вже наявні в системі, має бути інформаційне повідомлення, щодо їх перевірки. Повідомлення може бути одним по всім параметрам з подальшим їх виділенням іншим кольором. Процес видачі документа “Лікарське свідоцтво про смерть” та “Фельдшерська довідка про смерть” має проходити згідно схеми на Рис. 6.
Рис. 6. Схема процесу видачі документів  “Лікарське свідоцтво про смерть” та “Фельдшерська довідка про смерть” В Таблиця 13 описані загальні вимоги щодо документа “Лікарське свідоцтво про смерть” та “Фельдшерська довідка про смерть”. Таблиця 13. “Лікарське свідоцтво про смерть” та “Фельдшерська довідка про смерть”

Інформація, яка має автоматично підтягнутися до форми при переході з “Картка особи” та бути доступною для пошуку у випадку  “Формування документа”.

1. Персональна інформація:
   1. ПІБ матері – критерій для пошуку по БД
   2. ПІБ померлого – критерій для пошуку по БД
   3. Дата народження
   4. Національність
   5. 2.      Ідентифікаційна інформація:
      1. Серія та номер паспорта матері – критерій для пошуку по БД
      2. Реєстраційний номер облікової картки платника податків (матері)– критерій для пошуку по БД
      3. 3.      Постійне місце проживання:
         1. Адреса постійного місця проживання – критерій для пошуку по БД
         2. 4.      Чорнобильське посвідчення:*
            1. Наявність чорнобильського посвідчення у матері – ТАК/НІ

                                                                          i.            Серія посвідчення                                                                        ii.            Номер посвідчення

1. Наявність чорнобильського посвідчення у чоловіка – ТАК/НІ

                                                                          i.            Серія посвідчення                                                                        ii.            Номер посвідчення Де, * (у разі відсутності інформація по серії та номеру не виводити, виводити “не постраждав”). ВАЖЛИВО: По всіх даних, які вже наявні в системі, має бути інформаційне повідомлення, щодо їх перевірки. Повідомлення може бути одним по всіх параметрах з подальшим їх виділенням іншим кольором. Процес видачі документа “Лікарське свідоцтво про перинатальну смерть” має проходити згідно схеми на Рис. 7.
Рис. 7. Схема процесу видачі  документа “Лікарське свідоцтво про перинатальну смерть” У Таблиця 14 описані загальні вимоги щодо документа “Лікарське свідоцтво про перинатальну смерть” Таблиця 14. “Лікарське свідоцтво про перинатальну смерть”

Формування документа  має включати в себе функціонал згідно Таблиця 15. Таблиця 15. Опис стандартних функцій “Формування документа”

Видача дублікату документа щодо народження має відбуватися згідно схеми на
Рис. 8.
Рис. 8. Схема процесу видачі дублікату документа Інформація, що має видаватися для пошуку документа про народження, для видачі дублікату: 1)     Номер документа; 2)     Дата документа; 3)     ПІБ матері; 4)     Адреса матері; 5)     Реєстраційний номер облікової картки платника податків (матері); 6)     Серія та номер паспорта.
Система має надавати можливість відкривати знайдений документ для його перегляду та видачі дублікату. При виборі документа система має надавати можливість видати дублікат. Видача дублікату має відбуватися  з одночасним анулюванням попереднього документа і видачею нового.

Видача дублікату документа щодо смерті має відбуватися згідно схеми на Рис. 9.

Рис. 9. Схема процесу видачі нового документа Передбачити, що скан заяви про отримання нового документа має зберігатися в системі. Інформація, що має видаватися для пошуку документа про смерть, для видачі нового документа/дублікату: 1)     Номер документа; 2)     Дата документа; 3)     ПІБ матері; 4)     ПІБ померлого; 5)     Адреса матері; 6)     Реєстраційний номер облікової картки платника податків (матері); 7)     Реєстраційний номер облікової картки платника податків (померлого); 8)     Серія та номер паспорта матері/померлого; 9)     Тип документа. Система має надавати можливість відкривати знайдений документ для його перегляду та видачі нового документа/дублікату. При виборі документа система має надавати можливість вибрати варіант документа: 1)     Остаточний; 2)     Замість остаточного; 3)     Попередній; 4)     Замість попереднього; 5)     Дублікат. Видача нового документа має відбуватися з одночасним анулюванням попереднього документа і видачею нового. При видачі “замість остаточного” та “замість попереднього” система має виводити  попередній номер документа та проставляти новий номер з датою.

Редагування довідників має відбуватися згідно схеми на Рис. 10.
Рис. 10. Схема процесу редагування довідників Система має надавати можливість редагувати довідник, або додавати новий параметр до довідника. Редагування довідників  має включати в себе функціонал згідно Таблиця 16. Таблиця 16. Опис стандартних функцій “Редагування довідників”

Система має надавати можливість редагувати дані щодо працівників, які задіяні в процесі видачі документів. Інформація, що має видаватися для пошуку та бути доступною для  редагування: 1)     ПІБ працівника; 2)     Реєстраційний номер облікової картки платника податків (працівника); 3)     Посада працівника; 4)     Назва закладу; 5)     Адреса закладу; 6)     ЄДРПОУ закладу; 7)     Адреса головного закладу.
Інформація має редагуватися в межах закладу, для цього має бути назначено відповідальну особу за внесення коригуючої інформації – Адміністратор БП.
Формування документа  має включати в себе функціонал згідно Таблиця 17. Таблиця 17.Опис стандартних функцій “Редагування працівників”

Компонент АІС “СНДІ” Статистика призначений для формування звітності щодо народжених та померлих осіб. При формуванні звітів необхідно мати можливість формування:

• на дату (станом на _____ ) формувати інформацію про народжених чи померлих;
• з дати____ по дату______, формувати у визначений період;
• формувати з розбивкою помісячно, за визначений термін;
• формувати по типу виданого документу;
• у розрізі статі народженого/померлого;
• у розрізі ваги народжених та померлих;
• формувати у розрізі органу, що видав документ;
• друкувати у шапці показники, по яким фільтрується інформація (умови фільтрації) – не передбачено.

Компонент дозволяє створювати стандартні звіти. Функціональність щодо формування звітності для працівників охорони здоров’я за більшою кількістю критеріїв планується реалізовуватися у наступних етапах розробки Системи.
Перелік звітних форм:

1. Розподіл народжених і померлих за вагою тіла при народженні

При формуванні звіту необхідно мати можливість формування:

• у розрізі ваги народжених та померлих;
• на дату (станом на _____ ) формувати інформацію про народжених чи померлих;
• з дати____ по дату______, формувати у визначений період;
• з розбивкою помісячно, за визначений термін.

1. Звіт про кількість виданих документів

При формуванні звіту необхідно мати можливість формування:

• по типу виданого документу;
• за визначеним закладом, що видав документ;
• на дату (станом на _____) формувати інформацію про народжених чи померлих;
• з дати____ по дату______, формувати у визначений період;
• з розбивкою помісячно, за визначений термін.

1. Зведений звіт щодо померлих/народжених

При формуванні звіту необхідно мати можливість формування:

• у розрізі статі народженого/померлого;
• на визначену дату, на визначений період;
• з розбивкою помісячно, за визначений період;
• на визначений рік, за період років.

Формування звітів має включати в себе функціонал згідно Таблиця 18. Таблиця 18.Опис стандартних функцій “Статистика”

Документи щодо народження дитини: 1)     Анульовано – при прийнятті рішення, що в документі містяться помилки; 2)     Дублікат – видача нового документа замість втраченого, номер документа буде новим з поміткою, що документ є дублікатом 3)     Діючий – при підписанні договору всіма сторонами та набрання чинності договору; 4)     Тимчасовий – у випадку неповного заповнення документа і виходу з нього. Зміна статусу договору здійснюється тільки через виконання операцій або відповідно до логіки роботи автоматизованого процесу.   Документи щодо смерті особи: 1)     Діючий – при підписанні договору всіма сторонами та набрання чинності договору; 2)     Дублікат – видача нового документа замість втраченого, номер документа буде новим з поміткою, що документ є дублікатом (не діє для “Фельдшерська довідка про смерть”); 3)     “Попереднє” – видача документа відбувається  в  тих  випадках,  коли  для  встановлення чи уточнення причини  смерті  потрібно  провести  додаткові  дослідження (не діє для “Фельдшерська довідка про смерть”); 4)     “Замість   попереднього” – видається після того, як було, уточнено причини смерті(не діє для “Фельдшерська довідка про смерть”); 5)     “Остаточне” – видача документа відбувається  в  тих  випадках,  коли  для  встановлення чи уточнення причини  смерті не потрібно  проводити  дослідження (не діє для “Фельдшерська довідка про смерть”); 6)     “Замість остаточного” – видача документа відбувається  в  тих  випадках,  коли була виявлена помилка в записі діагнозу і необхідно заповнити  нове  лікарське  свідоцтво  у двох примірниках (не діє для “Фельдшерська довідка про смерть”); 7)     Анульовано – при прийнятті рішення, що в документі містяться помилки; 8)     Тимчасовий – у випадку неповного заповнення документа і виходу з нього. Зміна статусу договору здійснюється тільки через виконання операцій або відповідно до логіки роботи автоматизованого процесу.

Довідники, що використовуються в ІАС “СНДІ”   і є її невід’ємною частиною: Довідник типу вулиць

Довідник типу населених пунктів

Довідник країн світу, Довідник наповнюється згідно з Класифікацією країн світу

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

Довідник вулиць. Довідник наповнюється згідно з відповідним АРІ, по м. Києву, по іншим містам вручну

Довідник статі

Довідник місця смерті

Довідник причин смерті

Довідник підстав встановлення смерті

Довідник виду пологів

Довідник ознак доношеності

Довідник виду шлюбу

Довідник інших суттєвих станів

Довідник причин смерті дитини

Довідник статусу пологів

Довідник типів документів

Довідник посад лікарів, що прийняли пологи

Довідник ознаки адреси

Довідник виду документа

Довідник посад лікарів, Довідник заповнюється Адміністратором БП

Довідник часу настання смерті дитини

Довідник ким встановлена смерть

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

Порядок контролю та приймання ІАС “СНДІ” повинен відповідати етапам, наведеним у Таблиця 20.
Таблиця 20. Етапи контролю та приймання системи