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