Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Задля покращення взаємодії між користувачами, МІС та центральним компонентом, а також пришвидшення процесу ідентифікації інцидентів, та усунення інцидентів, кожна медична інформаційна система (МІС) повинна створити власну Сторінку моніторингу працездатності. 

...

Усі оновлення та зміни в статусах інцидентів повинні миттєво відображатися на сторінці статусу в режимі реального часу. 15 хвилинний термін з моменту виявлення інциденту в робочі години технічної підтримки МІС.

1.3. Швидке сповіщення персоналу та адміністратора

...

Система повинна систематично реєструвати та відстежувати критичні інциденти в роботі інфраструктури МІС та інциденти з високим впливом, що призводять до зупинення працездатності сервісів з переліку:

...

  • Авторизація та автентифікація

  • Запис медичних даних

  • Читання медичних даних

  • Інтеграція за зовнішніми системами через API

  • Інтеграція з ЦБД ЕСОЗ

2.3. Детальний опис інцидентів

Система повинна надавати можливість докладного опису інциденту, включаючи вплив на функціональність та можливі наслідки.

2.4. Статуси інцидентів

  • Різні статуси інцидентів

Для відображення динаміки проблем, які призводять до непрацездатності сервісів:

  • «Про проблему не повідомлялося»: на стороні МІС немає інформації щодо проблеми з компонентом.«Вивчається»: виявлено технічну проблему, фахівці МІС аналізують зміст та причину її виникнення.

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

  • «Моніторинг»: проблему вирішено, технічні фахівці МІС спостерігають за змінами для уникнення повторного виникнення проблеми.

  • «Вирішено»: проблему повноцінно вирішено.

  • На обслуговуванні”: на стороні МІС/ЕСОЗ тривають заплановані технічні роботи. Підстатуси: “не почалося”, “у процесі”, “виконано”.

2.5. Публічний доступ до статусів
Користувачі повинні мати можливість переглядати поточний статус кожного інциденту

2.6. Зберігання історії змін
Система повинні зберігати повну історію змін для кожного інциденту, включаючи дату, час змін, відповідальних за їх вирішення та коментарі. 

2.7. Доступ користувачів до історії
Історія інцидентів повинна бути доступна для перегляду всім користувачам системи. 

...

3.

...

Підписка для користувачів

3.1. Будь-який користувач повинен мати можливість підписатися на сповіщення про статус інцидентів.

...

3.2. Управління підписками

Система повинна забезпечити зручний інтерфейс для управління підписками та вибору типу сповіщень (SMS, електронна пошта, тощо.

       Адміністратору Адміністратору ЦБД має бути надана можливість використовувати web-hook та web API

...

3.3. Миттєві сповіщення для підписників

Підписники повинні отримувати миттєві сповіщення про нові інциденти, зміни статусу та закриття інцидентів.

34. Технічна специфікація https://github.com/svc-git/up

...