| Table of Contents |
|---|
Нефункціональні вимоги
| Tip |
|---|
|
Загальні рекомендації з відображення даних
| Panel | ||
|---|---|---|
| ||
Рекомендовано відображати дані тільки з одного джерела, з якого саме, повинно вирішується відносно кожному з атрибутів окремо. Одн з критеріїв для прийняття рішення- порівняння дат актуальності (оновлення) даних в обох джерелах. Приклад 1: Прізвище, Дата народження, Стать пацієнта: МІС може вважати локальні дані більш актуальними, навіть якщо у ЦК вони були оновлені пізніше. Приклад 2: Епізод чи Взаємодія можуть бути оновленими (змінено стан) локально у МІС, та зміни ще не передані до ЦК. Відповідно, у ЦК дані Епізоду будуть старіші, ніж їх локальна версія у МІС. У даному випадку доречно відображати дані з МІС. Приклад 3: дата оновлення Епізоду чи Взаємодії у ЦК більша, за дату оновлення у МІС. У такому разі необхідно оновити дані у МІС. Приклад 4: Взаємодія існує локально у МІС, але ще не передана до ЦК (передавання не виконувалось або знаходиться у процесі обробки). У такому разі відображаються дані з МІС. |
| Panel | ||
|---|---|---|
| ||
Для кожного такого параметру необхідно визначити, чи буде він актуальним, якщо дата оновлення запису у ЦК та у МІС відрізняються у той чи інший бік, та відповідно до цього відображати чи не відображати такі дані користувачу. Приклад: локальний коментар щодо Пацієнта та особливостей роботи з ним, локальні примітки до Епізоду. |
| Panel | ||
|---|---|---|
| ||
Рекомендовано відображати дані з обох джерел з відповідною позначкою. Приклад: контактна інформація Пацієнта (телефони, e-mail, viber тощо). |
| Panel | ||
|---|---|---|
| ||
Для кожної з використовуваних сутностей, які синхронізуються з ЦК, рекомендовано відображати дату та час останньої успішної синхронізації з ЦК для того, щоб користувач мав змогу оцінити ступінь актуальності даних. |
Рекомендації з імплементації функціональних вимог
Робоче місце лікаря
tipПовинне надавати можливість:
Бажано відображати перелік пацієнтів, які мають запис на прийом з даним лікарем на обрану дату. Формування такого переліку виконується МІС на підставі локальних даних.
Сортування за датою та часом візиту в порядку зростання.
Для обслуговування пацієнтів, які прийшли на прийом без запису, лікар повинен мати можливість знайти пацієнта за даними, які створені та зберігаються у МІС, або створити новий локальний запис пацієнта.
Лікар повинен мати можливість відкрити картку пацієнта безпосередньо із кожного запису.
Лікар ПМД повинен мати можливість перегляду переліку підписаних з ним або з лікарями його медичного закладу декларацій. За замовчуванням повинні відображатися лише активні декларації поточного користувача, з можливістю відображення неактивних або одразу всіх декларацій та пошуку декларації за її параметрами.
Для отримання таких даних з ЦК необхідно виконати виклик Отримання декларацій
Сортування по Прізвищу, Ім’ям та По-батькові пацієнта у алфавітному порядку.
Лікар повинен мати можливість відкрити картку пацієнта безпосередньо із кожного запису.
Лікар повинен мати можливість відкрити дані декларації безпосередньо із кожного запису. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних декларації
Expand title Приклади до вимог Заплановані візити до лікаря
Зареєстровані пацієнти
Декларації, які підписав лікар
Картка пацієнта
Картка пацієнта повинна надавати можливість:
перегляду сумарної (важливої) інформації про пацієнта:
ПІБ, Вік (дата народження), стать пацієнта. Для лікаря ПМД, у медичному закладі якого підписано декларацію із пацієнтом, для отримання таких даних з ЦК можливо виконати виклик Отримання даних декларації пацієнта. Для всіх лікарів буде доступний окремий API з отримання демографічних даних пацієнта.
алергії/непереносимості (Allergy Intolerances), записи про імунізації (Immunizations), особливі стани (Summary Conditions), діагнози за відкритими епізодами (Summary Active Diagnoses) та спостереження , ризики (Risk Assessments), пристрої (Devices), прийом ЛЗ (Medication Statement). Для отримання таких даних з ЦК необхідно виконати виклики Отримання зведеної інформації пацієнта.
Позначку про відсутність активної декларації у пацієнта в ЦК. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних декларації пацієнта.
Дані лікаря, з яким підписано декларацію у пацієнта, у випадку, якщо вона підписана з іншим лікарем. Для лікаря ПМД, у медичному закладі якого підписано декларацію із пацієнтом, для отримання таких даних з ЦК можливо виконати виклик Отримання даних декларації пацієнта. Для всіх лікарів буде доступний окремий API з отримання даних лікаря, з яким підписано декларацію пацієнта.
У разі, якщо у пацієнта немає активної декларації або запис пацієнта у МІС не пов’язаний із записом пацієнта у ЦК, лікар ПМД повинен мати можливість перейти до процесу пошуку пацієнта у ЦК та створення із ним декларації.
Перегляду епізодів МД та взаємодій у розрізі епізодів МД та візитів.
рекомендовано за замовчуванням відображати відкриті епізоди та надати лікарю можливість відобразити закриті чи одразу всі епізоди пацієнта
лікар повинен мати можливість бачити, чи є він Care Manager у кожному з епізодів без переходу до картки епізоду за допомогою відповідної позначки або фільтру. Залежно від цього рекомендовано попереджати лікаря у разі спроби зміни епізоду чи додавання взаємодії до епізоду іншого лікаря.
Лікар повинен мати можливість відкрити картку епізоду.
Сортування даних за замовчуванням: від нових до старих.
МІС має надавати змогу відображати взаємодії, згруповані у епізоди МД та візити пацієнта (див. тренажер). Для виконання такого групування на основі даних з ЦК необхідно виконати виклики Отримання епізодів за параметрами та Отримання взаємодій за параметрами, після чого згрупувати дані відповідним чином.
МІС має надавати змогу пошуку взаємодій у відповідності до пошукових параметрів, визначених в API.
При перегляді взаємодій у розрізі епізодів:
Лікар повинен мати можливість переглянути додаткову інформацію по кожному коду ICPC-2 (див. тренажер). Значення тут.
Лікар повинен мати можливість відкрити картку взаємодії безпосередньо із кожної взаємодії.
Лікар повинен мати можливість змінити епізод. Для зміни епізоду в ЦК необхідно виконати виклик Зміна епізоду.
Лікар повинен мати можливість відкрити картку епізоду безпосередньо з кожного запису.
Лікар повинен мати можливість створення епізоду. Для створення епізоду в ЦК необхідно виконати виклик Створення епізоду
Виконати процес створення взаємодії із переліку епізодів та взаємодій:
При додаванні взаємодії до існуючого епізоду:
якщо діагноз не змінюється, необхідно посилатися на існуючий Condition.
якщо основний діагноз епізоду МД змінюється, необхідно про це повідомити і запитати підтвердження користувача (див. тренажер).
Роль, статус діагнозу, клінічний статус, стадія захворювання, ступінь тяжкості, ранк, і т.д. - для цих полів бажано мати значення за замовчуванням (але надати можливість їх змінювати), щоб не перевантажувати лікаря ПМД. В більшості випадків вони будуть наперед визначені. Так, наприклад, очевидно, що якщо діагноз один, то він буде основним і ранк для нього не матиме сенсу.
(роль - основний , статус достовірності - заключний, клінічний статус - активний, стадія захворювання - значення за замовчуванням, ступінь тяжкості - середній)При введенні причин звернення, діагнозу, дій, для кожного коду має бути змога ввести додатковий текстовий коментар.
Створення і управління взаємодіями та епізодами на рівні ПМД загалом мають відображати логіку ICPC-2 (див. тренажер) з причинами, діагнозом та діями.
При створенні взаємодії у рамках нового епізоду МД бажано за замовчуванням називати епізод відповідно до основного діагнозу взаємодії/епізоду.
При створенні взаємодії у рамках існуючого епізоду МД рекомендовано попереджати лікаря у разі додавання взаємодії до епізоду іншого лікаря.
При створенні взаємодії за допомогою покрокового переходу між сторінками з даними взаємодії, лікар повинен мати можливість:
бачити дані, заповнені на пройдених етапах створення взаємодії
повернутися до вже пройденого етапу створення взаємодії та відкоригувати введені дані за потребою.
Для створення епізоду в ЦК необхідно виконати виклик Створення епізоду
Для передавання в ЦК взаємодії необхідно виконати виклик Створення взаємодії.
Перегляду динаміки спостережень пацієнта: однотипні спостереження (за кодом спостереження), зафіксовані у визначений проміжок часу безвідносно до епізодів, взаємодій, діагностичних звітів, до яких вони відносяться (наприклад, перегляд динаміки вимірювань тиску).
Для отримання таких даних з ЦК необхідно виконати виклик Отримання спостережень за параметрами передаючи код спостереження та період.
Лікар повинен мати можливість переходу до картки взаємодії чи діагностичного звіту, у рамках якого було зафіксовано спостереження.
Перегляду рецептів, виписаних пацієнту:
Для отримання таких даних з ЦК необхідно виконати виклик Отримання рецептів за параметрами
Повинна бути можливість пошуку за станом рецепту.
Сортування за замовчуванням - по даті створення рецепту.
Для кожного рецепту повинна відображатися позначка наявності відпуску ліків за рецептом. Для отримання таких даних з ЦК необхідно виконати виклик Отримання відпусків за рецептом.
Для кожного рецепту повинна бути можливість виконання переходу до картки рецепту.
Перегляду переліку діагностичних звітів пацієнта -TBC
| Expand | ||
|---|---|---|
| ||
Важлива інформація про пацієнта Епізоди та взаємодії пацієнта із групуванням та без Динаміка спостережень пацієнта Рецепти, виписані пацієнту Діагностичні звіти пацієнта |
Картка епізоду
Картка епізоду повинна надавати можливість:
перегляду даних епізоду. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних епізоду
перегляду всіх взаємодій, які були зафіксовані у рамках епізоду. Для отримання таких даних з ЦК необхідно виконати виклик Отримання взаємодій за параметрами
перегляду консультаційних висновків, які були надані за направленнями епізоду (взаємодії, які були створені іншими лікарями при виконанні дій за направленням, виписаним у рамках епізоду) із можливістю переходу до картки такої взаємодії - TBC
перегляду рецептів, виписаних у рамках взаємодій епізоду. Вимоги до відображення рецептів та дій із ними аналогічні до вимог з відображення рецептів у картці пацієнта.
перегляду направлень, виписаних у рамках взаємодій епізоду, із можливістю переходу до взаємодії чи картки направлення - TBC
Перегляду діагностичних звітів, наданих за направленнями епізоду із можливістю переходу до взаємодії чи картки діагностичного звіту - TBC
закриття епізоду із зазначенням причини та резюме до закриття. Для закриття епізоду в ЦУ необхідно виконати виклик Закриття епізоду
позначення епізоду як введеного помилково:
Ця функціональність - не є частиною звичайного процесу. Відповідно, лікар має бути повідомлений про те, що усі документи, які позначені помилковими, залишаються в системі, можуть бути переглянуті адміністраторами і тд. При кожній такій операції МІС має додатково отримати підтвердження користувача.
Для позначення в ЦК епізоду як введеного помилково необхідно виконати виклик Позначення епізоду як введеного помилково.
виконати процес створення взаємодії. Вимоги до реалізації процесу наведені у розділі Картка пацієнта.
| Expand | ||
|---|---|---|
| ||
Картка епізоду та його дані |
Картка взаємодії
Картка взаємодії повинна надавати можливість:
перегляду даних взаємодії. Для отримання таких даних з ЦК необхідно виконати виклик Отримання даних взаємодії
виконати процес створення направлення пов’язаного із взаємодією - TBC
виконати процес створення рецепту пов’язаного із взаємодією, у рамках якої створюється рецепт. Створення запиту на рецепт, його перевірка та підписання у ЦК виконуються за допомогою викликів, визначених у Запит на рецепт.
перегляду алергій/непереносимостей, імунізацій, станів, спостережень, ризиків, пристроїв та записів про прийом ЛЗ, які були зафіксовані у рамках взаємодії. Для отримання таких даних необхідно виконати виклики, визначені у Отримання медичних даних пацієнта.
перегляду рецептів, виписаних у рамках взаємодії. Вимоги до відображення рецептів та дій із ними аналогічні до вимог з відображення рецептів у картці пацієнта.
перегляду направлень, виписаних у рамках взаємодії, із можливістю переходу до картки направлення - TBC
позначення взаємодії як введеної помилково:
Ця функціональність - не є частиною звичайного процесу. Відповідно, лікар має бути повідомлений про те, що усі документи, які позначені помилковими, залишаються в системі, можуть бути переглянуті адміністраторами і тд. При кожній такій операції МІС має додатково отримати підтвердження користувача.
Текст для відображення користувачу:
Заголовок - Підтвердження щодо визначення помилково внесеної медичної документації про пацієнта
Для коментаря (explanatory_letter) - Обґрунтування підстав визначення помилкового внесення медичної документації
Після введення коментаря - Медична документація, яка визначена такою, що внесена помилково, зберігається в електронній системі охорони здоров’я!Для позначення в ЦК взаємодії, як введеної помилково, необхідно виконати виклик відповідного ендпоінту.
| Expand | ||
|---|---|---|
| ||
Картка взаємодії та її дані |
Картка рецепту
Картка рецепту повинна надавати можливість:
перегляду даних рецепту. Для отримання таких даних необхідно виконати виклик Отримання рецепту
перегляду переліку відпусків за рецептом. Для отримання таких даних з ЦК необхідно виконати виклик Отримання відпусків за рецептом
відміни рецепту за допомогою виклику Відкликання рецепту
Expand title Приклади до вимог
Картка направлення - TBC
Картка діагностичного звіту - TBC
...