ЕСОЗ - публічна документація
Реєстрація результатів візиту в ЦК
Overview
Процес "Реєстрація результатів візиту в ЦК" описує процес збору, підготовки та подачі даних до ЦК, зібраних протягом одного візиту. В залежності від ситуації, під час візиту у лікаря може виникнути необхіднісь створити новий епізод, змінити або закрити існуючий, зараєструвати результати обстежень, щеплення, алергії, або діагнози хворого. Також, під час одного візиту лікар може працювати з декільками проблемами пацієнта, які будуть зараєстровані як окремі взаємодії, але об'єднані одиним візитом.
Проміжні результати роботи лікаря зберігаються в МІС, передача фінального пакету даних, зібраних під час візиту, відбувається наприкінці візиту.
eHealth не регламентує процес/послідовність в якій лікар заповнює документацію та обслуговує пацієнта - це залишається на розсуд ЗОЗ.
Goals
- Зібрати актуальну медичну інформацію про пацієнта, опираючись на попередньо зареєстровані дані
- Надати медичну допомогу опираючись на зібрану інформацію
- Подати результати візиту до ЦК
Business Process Diagram
1. "Реєстрація результатів візиту в ЦК"
№ | Step | Description |
---|---|---|
1 | Надання медичних послуг | Лікар спілкується з пацієнтом, надає медичну допомогу згідно ситуації. При цому, лікар може парелельно вносити дані до системи, або ж перейти до кроку 1.4, після того як надасть медичні послуги, згідно до бізнес-процесу, імплементованого в конкретному ЗОЗ. |
2 | Запомнення медичної документації в МІС | Лікар послідовно вносить дані до МІС (дивись приклад нижче) |
3 | Підтвердження сформованої документації та накладання ЕЦП | Лікар перевіряє документи(консультаційні висновки), сформовані підчас візиту, та накладає свій електронно-цифровий підпис. У склад пакету Encounter Package може входити діагностичний звіт, у разі, якщо лікар переніс його зі звіту, наданого пацієнтом. |
4 | Подача результатів візиту до ЦК | Лікар підтверджує відправку результатів візиту до ЦК. При цьому результати візиту може передати тільки медичний заклад, який має активний та верифікований NHS тип PRIMARY_CARE (MSP, MSP_PHARMACY) або OUTPATIENT Вимоги до складу пакету даних із результатами візита, залежать від класу взаємодії, яка входить у пакет. Перелік класів взаємодій, які може реєструвати лікар, залежить від типу медичного закладу, від імені якого подаються дані. Якщо взаємодія відбувалась за направленням, пакет даних повинен містити посилання на послугу, яка відповідає послузі або групі послуг у направленні (посилання на послугу може міститися у діях у вигляді посилань на послуги, процедурах чи діагностичних звітах, що входять до складу пакету). Така перевірка не виконується для направлень на госпіталізацію та переведення у інший ЗОЗ. Пакет даних повинен бути підписаним лікарем, визначеним як Performer у взаємодії. |
5 | Створення направлення | За потреби направити пацієнта на отримання послуг поза рамками поточного підвізиту, лікар повинен виписати направлення на кожну необхідну послугу, безвідносно до місця надання таких послуг. Виконуються дії процесу Створення направлення |
6 | Створення рецепту | За потреби призначити пацієнту лікувальні препарати, визначити графік їх прийому, та/або виписати рецепт на лікувальні препарати, лікар повинен виписати рецепт на кожний такий препарат. Виконуються дії процесу БП Створення електроного рецепту (Create Medication Request BP). |
2. Приклад процесу заповнення даних по візиту в МІС*
*-на діаграмі зображений приклад процесу. ЗОЗ залишає за собою право самостійно визначати послідовність та набір дій, які виконуються на візиті.
Також, МІС залишає за собою право самостійно визначати в який момент виконувати виклики веб-сервісів (одразу після створення об'єкту в МІС, або ж наприкінці візиту)
№ | Step | Description |
---|---|---|
1 | Визначити чи необхідно створити новий епізод | |
2 | Створити епізод | |
3 | Визначити чи необхідно змінити назву епізоду | Назва епізоду - це допоміжна характеристика епізоду, яка допомогає лікарю орієнтуватися в списку епізодів |
4 | Змінити назву епізоду | |
5 | Створити візит | Візит - це адміністративний об'єкт, необхідний для групування взаємодій |
6 | Створити взаємодію | Взаємодія - це основний артефакт візиту. Лікар має обов'язково заповнити причину, діагноз та дію. Дозволяється посилання на існуючий Стан, у основному Діагнозі енкаунтера у випадку, якщо система кодування даного стану (ICPC2 або ICD10_AM) відповідає рівню надання допомоги на якому створюється енкаунтер (ПМД - ICPC2, СМД - ICD10_AM). Дозволяється посилання на існучий Стан в якості супутнього або ускладненого Діагнозу енкаунтера, незалежно від того у якій системі кодування створено даний діагноз. |
7 | В залежності від ситуації, лікар може створити наступні об'єкти: | |
8 | Заповнити обстеження | |
9 | Заповнити діагнози (стани) | Впродовж взаємодії, лікар може зареєструвати як поточні діагнози (стани), так і історичні. Історичні діагнози (стани), які не є предметом лікування поточного епізоду, не зазначаються в блоці "Діагнози" взаємодії і не буть відображені в історіїї діагнозів епізоду. |
10 | Заповнити алергії | |
11 | Заповнити імунізації | |
12 | Заповнити оцінки ризиків | |
13 | Заповнити лікарські засоби | Лікар заповнює записи про прийом лікарських засобів |
14 | Заповнити пристрої | |
15 | Заповнити процедури | У рамках взаємодії із пацієнтом лікар може виконати одну чи більше процедур та надати записи про це до ЦК. При цьому кожна процедура має містити у собі посилання на поточний підвизит, а якщо вона виконувалась за направленням, посилання на направлення, за яким вона виконувалась. Для кожної процедури можливо надати посилання на підстави, за якими прийнято рішення про її виконання (діагнози та інші процедури поточного підвизиту, діагностичні звіти), посилання на ускладнення, які виникли під час, або безпосередньо після та в наслідок виконання процедури (діагнози поточного підвизиту). Вимоги до складу процедури у складі Encounter Data Package відповідають вимогам до cкладу процедури, що надається окремо (див. Реєстрація запису про проведену процедуру в ЦК) |
16 | Заповнити діагностичні звіти | У рамках взаємодії із пацієнтом лікар може виконати одну чи більше діагностичних процедур та надати записи про це до ЦК. При цьому кожний діагностичний звіт має містити у собі посилання на поточний підвизит, а якщо діагностична процедура виконувалась за направленням, посилання на направлення, за яким вона виконувалась. Вимоги до складу діагностичного звіту у складі Encounter Data Package відповідають вимогам до cкладу діагностичного звіту, що надається окремо (див. Внесення результатів досліджень та їх передача до ЦК) |
17 | ||
18 | Визначити, чи необхідно виписати направлення або рецепт | |
19 | Визначити, чи необхідно закрити епізод | |
20 | Закрити епізод, вказати причину |
В рамках пакету взаємодії лікар може реєструвати записи про діагностичний звіт або процедуру, які були отримані пацієнтом у іншому НМП.
Рекомендовані правила заповнення реквізитів для Діагностичного звіту:
Рекомендований переклад | Атрибут | Значення | |
---|---|---|---|
внесення результатів діагностичного звіту, які були отримані пацієнтом у іншому МНП | внесення результатів діагностичного звіту, які були отримані пацієнтом безпосередньо у користувача | ||
первинне джерело | primary_source | FALSE | TRUE |
посилання на джерело | report_origin | Codeable_Concept | НЕ ЗАПОВНЮЄТЬСЯ |
виконавець | performer.text | "Опанасенко Олексій Володимирович" | НЕ ЗАПОВНЮЄТЬСЯ |
виконавець | performer.reference | НЕ ЗАПОВНЮЄТЬСЯ | employee_id |
працівник що інтерпретував результати | results_enterpreter.reference | НЕ ЗАПОВНЮЄТЬСЯ | employee_id |
Рекомендовані правила заповнення реквізитів для Процедури:
Рекомендований переклад | Атрибут | Значення | |
---|---|---|---|
внесення результатів діагностичного звіту, які були отримані пацієнтом у іншому МНП | внесення результатів діагностичного звіту, які були отримані пацієнтом безпосередньо у користувача | ||
первинне джерело | primary_source | FALSE | TRUE |
посилання на джерело | report_origin | Codeable_Concept | НЕ ЗАПОВНЮЄТЬСЯ |
виконавець | performer.text | "Опанасенко Олексій Володимирович" | НЕ ЗАПОВНЮЄТЬСЯ |
виконавець | performer.reference | НЕ ЗАПОВНЮЄТЬСЯ | employee_id |
Примітка: кольором позначено атрибути, один з яких обов'язковий
3. Приклад реєстрації реакції на імунізацію
# | Step | Description |
---|---|---|
1 | Звернення пацієнта з реакцією на імунізацію | Пацієнт звернувся зі скаргами. Існує ймовірність, що скарги пов'язані з попередньо проведеною імунізацією. |
2 | Пошук імунізації в ЦК, визначення взаємозв'язку симптомів та імунізації | Лікар виконує пошук імунізації з метою визначити чи мала місце імунізація останнім часом та чи могла вона стати причиню симптомів пацієнта. |
3 | Створення візиту | Лікар створює новий візит |
4 | Створення взаємодії з вказанням причини, діагнозу, дії | Лікар реєструє ІСРС2-взаємодію - вказує причину, діагноз та дії, які необхідно виконати за результатами візиту |
5 | Зареєструвати обстеження з посиланням на імунізацію(reaction_on) | Лікар реєструє результати виконаних обстеженнь на базі скарг пацієнта, наприклад заміряну температуру, почервоніння шкіри, висипання; та посилається на імунізацію з якою вони пов'язані (поле reaction_on). |
6 | Зареєструвати обстеження без посилання на імунізацію | У разі, коли обстеження не пов'язані з імунізацією, лікар реєструє їх, залишаючи поле reaction_on не заповненим. |
7 | Результати візиту сформовано в МІС | Пакет даних взаємодії сформований у МІС та може бути переданий до ЦК, як показано в БП №1 |
ЕСОЗ - публічна документація