Нефункціональні вимоги

Загальні рекомендації з відображення даних

Рекомендації з імплементації функціональних вимог

Робоче місце лікаря

Повинне надавати можливість: 

1. Бажано відображати перелік пацієнтів, які мають запис на прийом з даним лікарем на обрану дату. Формування такого переліку виконується МІС на підставі локальних даних.

1. Сортування за датою та часом візиту в порядку зростання.

2. Для обслуговування пацієнтів, які прийшли на прийом без запису, лікар повинен мати можливість знайти пацієнта за даними, які створені та зберігаються у МІС, або створити новий локальний запис пацієнта.

3. Лікар повинен мати можливість відкрити картку пацієнта безпосередньо із кожного запису.

2. Лікар ПМД повинен мати можливість перегляду переліку підписаних з ним або з лікарями його медичного закладу декларацій. За замовчуванням повинні відображатися лише активні декларації поточного користувача, з можливістю відображення неактивних або одразу всіх декларацій та пошуку декларації за її параметрами.

1. Для отримання таких даних з ЦК необхідно виконати виклик  Отримання декларацій

2. Сортування по Прізвищу, Ім’ям та По-батькові пацієнта у алфавітному порядку.

3. Лікар повинен мати можливість відкрити картку пацієнта безпосередньо із кожного запису.

4. Лікар повинен мати можливість відкрити дані декларації безпосередньо із кожного запису. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних декларації

    Приклади до вимог

   Заплановані візити до лікаря

   

   ---

   Зареєстровані пацієнти

   

   ---

   Декларації, які підписав лікар

   

Картка пацієнта

Картка пацієнта повинна надавати можливість: 

1. перегляду сумарної (важливої) інформації про пацієнта: 

1. ПІБ, Вік (дата народження), стать пацієнта. Для лікаря ПМД, у медичному закладі якого підписано декларацію із пацієнтом, для отримання таких даних з ЦК можливо виконати виклик Отримання даних декларації пацієнта. Для всіх лікарів буде доступний окремий API з отримання демографічних даних пацієнта.

2. алергії/непереносимості (Allergy Intolerances), записи про імунізації (Immunizations), особливі стани (Summary Conditions), діагнози за відкритими епізодами (Summary Active Diagnoses) та спостереження , ризики (Risk Assessments), пристрої (Devices), прийом ЛЗ (Medication Statement). Для отримання таких даних з ЦК необхідно виконати виклики Отримання зведеної інформації пацієнта.

3. Позначку про відсутність активної декларації у пацієнта в ЦК. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних декларації пацієнта. 

4. Дані лікаря, з яким підписано декларацію у пацієнта, у випадку, якщо вона підписана з іншим лікарем. Для лікаря ПМД, у медичному закладі якого підписано декларацію із пацієнтом, для отримання таких даних з ЦК можливо виконати виклик Отримання даних декларації пацієнта. Для всіх лікарів буде доступний окремий API з отримання даних лікаря, з яким підписано декларацію пацієнта.

5. У разі, якщо у пацієнта немає активної декларації або запис пацієнта у МІС не пов’язаний із записом пацієнта у ЦК, лікар ПМД повинен мати можливість перейти до процесу пошуку пацієнта у ЦК та створення із ним декларації.
   
   

2. Перегляду епізодів МД та взаємодій у розрізі епізодів МД та візитів. 

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

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

   3. Лікар повинен мати можливість відкрити картку епізоду.

   4. Сортування даних за замовчуванням: від нових до старих.

1. МІС має надавати змогу відображати взаємодії, згруповані у епізоди МД та візити пацієнта (див. тренажер). Для виконання такого групування на основі даних з ЦК необхідно виконати виклики Отримання епізодів за параметрами та Отримання взаємодій за параметрами, після чого згрупувати дані відповідним чином.

2. МІС має надавати змогу пошуку взаємодій у відповідності до пошукових параметрів, визначених в API.

3. При перегляді взаємодій у розрізі епізодів:

4. Лікар повинен мати можливість переглянути додаткову інформацію по кожному коду ICPC-2 (див. тренажер). Значення тут.

5. Лікар повинен мати можливість відкрити картку взаємодії безпосередньо із кожної взаємодії.

6. Лікар повинен мати можливість змінити епізод. Для зміни епізоду в ЦК необхідно виконати виклик Зміна епізоду.

7. Лікар повинен мати можливість відкрити картку епізоду безпосередньо з кожного запису.

8. Лікар повинен мати можливість створення епізоду. Для створення епізоду в ЦК необхідно виконати виклик Створення епізоду 
   
   

3. Виконати процес створення взаємодії із переліку епізодів та взаємодій:

1. При додаванні взаємодії до існуючого епізоду:

   1. якщо діагноз не змінюється, необхідно посилатися на існуючий Condition.

   2. якщо основний діагноз епізоду МД змінюється, необхідно про це повідомити і запитати підтвердження користувача (див. тренажер).

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

3. При введенні причин звернення, діагнозу, дій, для кожного коду має бути змога ввести додатковий текстовий коментар.

4. Створення і управління взаємодіями та епізодами на рівні ПМД загалом мають відображати логіку ICPC-2 (див. тренажер) з причинами, діагнозом та діями.

5. При створенні взаємодії у рамках нового епізоду МД бажано за замовчуванням називати епізод відповідно до основного діагнозу взаємодії/епізоду. 

6. При створенні взаємодії у рамках існуючого епізоду МД рекомендовано попереджати лікаря у разі додавання взаємодії до епізоду іншого лікаря.

7. При створенні взаємодії за допомогою покрокового переходу між сторінками з даними взаємодії, лікар повинен мати можливість:

   1. бачити дані, заповнені на пройдених етапах створення взаємодії

   2. повернутися до вже пройденого етапу створення взаємодії та відкоригувати введені дані за потребою.

8. Для створення епізоду в ЦК необхідно виконати виклик Створення епізоду

9. Для передавання в ЦК взаємодії необхідно виконати виклик Створення взаємодії.
   
   

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

1. Для отримання таких даних з ЦК необхідно виконати виклик Отримання спостережень за параметрами передаючи код спостереження та період.

2. Лікар повинен мати можливість переходу до картки взаємодії чи діагностичного звіту, у рамках якого було зафіксовано спостереження.

1. Перегляду рецептів, виписаних пацієнту:

1. Для отримання таких даних з ЦК необхідно виконати виклик Отримання рецептів за параметрами

2. Повинна бути можливість пошуку за станом рецепту.

3. Сортування за замовчуванням - по даті створення рецепту.

4. Для кожного рецепту повинна відображатися позначка наявності відпуску ліків за рецептом. Для отримання таких даних з ЦК необхідно виконати виклик Отримання відпусків за рецептом.

5. Для кожного рецепту повинна бути можливість виконання переходу до картки рецепту.

6. Перегляду переліку діагностичних звітів пацієнта -TBC

Картка епізоду

Картка епізоду повинна надавати можливість:

1. перегляду даних епізоду. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних епізоду

2. перегляду всіх взаємодій, які були зафіксовані у рамках епізоду. Для отримання таких даних з ЦК необхідно виконати виклик Отримання взаємодій за параметрами

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

4. перегляду рецептів, виписаних у рамках взаємодій епізоду. Вимоги до відображення рецептів та дій із ними аналогічні до вимог з відображення рецептів у картці пацієнта.

5. перегляду направлень, виписаних у рамках взаємодій епізоду, із можливістю переходу до взаємодії чи картки направлення - TBC

6. Перегляду діагностичних звітів, наданих за направленнями епізоду  із можливістю переходу до взаємодії чи картки діагностичного звіту - TBC

7. закриття епізоду із зазначенням причини та резюме до закриття. Для закриття епізоду в ЦУ необхідно виконати виклик Закриття епізоду

8. позначення епізоду як введеного помилково:

1. Ця функціональність - не є частиною звичайного процесу. Відповідно, лікар має бути повідомлений про те, що усі документи, які позначені помилковими, залишаються в системі, можуть бути переглянуті адміністраторами і тд. При кожній такій операції МІС має додатково отримати підтвердження користувача. 

2. Для позначення в ЦК епізоду як введеного помилково необхідно виконати виклик Позначення епізоду як введеного помилково.

9. виконати процес створення взаємодії. Вимоги до реалізації процесу наведені у розділі Картка пацієнта.

Картка взаємодії

Картка взаємодії повинна надавати можливість:

1. перегляду даних взаємодії. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних взаємодії

2. виконати процес створення направлення пов’язаного із взаємодією - TBC

3. виконати процес створення рецепту пов’язаного із взаємодією, у рамках якої створюється рецепт. Створення запиту на рецепт, його перевірка та підписання у ЦК виконуються за допомогою викликів, визначених у Запит на рецепт. 

4. перегляду алергій/непереносимостей, імунізацій, станів, спостережень, ризиків, пристроїв та записів про прийом ЛЗ, які були зафіксовані у рамках взаємодії. Для отримання таких даних необхідно виконати виклики, визначені у Отримання медичних даних пацієнта.

5. перегляду рецептів, виписаних у рамках взаємодії. Вимоги до відображення рецептів та дій із ними аналогічні до вимог з відображення рецептів у картці пацієнта.

6. перегляду направлень, виписаних у рамках взаємодії, із можливістю переходу до картки направлення - TBC

7. позначення взаємодії як введеної помилково:

1. Ця функціональність - не є частиною звичайного процесу. Відповідно, лікар має бути повідомлений про те, що усі документи, які позначені помилковими, залишаються в системі, можуть бути переглянуті адміністраторами і тд. При кожній такій операції МІС має додатково отримати підтвердження користувача. 

   Текст для відображення користувачу:

   Заголовок - Підтвердження щодо визначення помилково внесеної медичної документації про пацієнта
   Для коментаря (explanatory_letter) - Обґрунтування підстав визначення помилкового внесення медичної документації
   Після введення коментаря - Медична документація, яка визначена такою, що внесена помилково, зберігається в електронній системі охорони здоров’я!

2. Для позначення в ЦК взаємодії, як введеної помилково, необхідно виконати виклик відповідного ендпоінту.

Картка рецепту

Картка рецепту повинна надавати можливість:

1. перегляду даних рецепту. Для отримання таких даних необхідно виконати виклик Отримання рецепту

2. перегляду переліку відпусків за рецептом. Для отримання таких даних з ЦК необхідно виконати виклик Отримання відпусків за рецептом

3. відміни рецепту за допомогою виклику Відкликання рецепту

    Приклади до вимог

   

Картка направлення - TBC

Картка діагностичного звіту - TBC