ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

Overview

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

eHealth не регламентує процес/послідовність в якій лікар заповнює документацію та обслуговує пацієнта - це залишається на розсуд ЗОЗ.

Goals

  1. Зібрати актуальну медичну інформацію про пацієнта, опираючись на попередньо зареєстровані дані
  2. Надати медичну допомогу опираючись на зібрану інформацію
  3. Подати результати візиту до ЦК


Business Process Diagram

1. "Реєстрація результатів візиту в ЦК"

StepDescription
1.1Пошук пацієнта та визначення режиму роботи з данимиПершочергово лікар (або співробітник рецепції) має знайти пацієнта в системі eHealth та визначити в якому режимі він буде працювати з даними пацієнта.
У випадку, коли користувач є лікарам первинної ланки та має активну підписану декларацію з пацієнтом, він може отримати повний доступ до всіх медичних даних пацієнта. Якщо ж пацієнт поки що не має декларації або хоче перезаключити її з поточним лікарем, ця операція може бути виконана на місці, після чого лікар отримає повний доступ.
Якщо ж лікар не має активної  декларації з пацієнтом, проте має підставу для отримання розширеного доступу до даних пацієнта, наприклад направлення, воно може бути використано для отримання розширеного доступу. 
Лікар може отримати обмежений доступ через Patient summary до даних пацієнта, якщо в нього немає підстав для отримання розширеного або повного доступу. 
1.2Ознайомлення з історією пацієнтаПісля отримання доступу до даних, лікар, в доступному йому режимі, може ознайомитися з необхідними медичними даними пацієнта.
1.3Надання медичних послугЛікар спілкується з пацієнтом, надає медичну допомогу згідно ситуації. При цому, лікар може парелельно вносити дані до системи, або ж перейти до кроку 1.4, після того як надасть медичні послуги, згідно до бізнес-процесу, імплементованого в конкретному ЗОЗ.
1.4Запомнення медичної документації в МІСЛікар послідовно вносить дані до МІС. Приклад процесу заповнення даних.
1.5Підтвердження сформованої документації та накладання ЕЦП

Лікар перевіряє документи(консультаційні висновки), сформовані підчас візиту, та накладає свій електронно-цифровий підпис.

У склад пакету Encounter Package може входити діагностичний звіт, у разі, якщо лікар переніс його зі звіту, наданого пацієнтом.

1.6Подача результатів візиту до ЦК

Лікар підтверджує відправку результатів візиту до ЦК.
МІС послідовно здійснює виклик необхідних веб-сервісів для передачі даних до ЦК в автоматичному режимі.

(warning) При цьому результати візиту може передати тільки медичний заклад, який має активний та верифікований NHS тип PRIMARY_CARE (MSP, MSP_PHARMACY) або OUTPATIENT

2. "Пошук пацієнта та визначення режиму роботи з даними"

StepDescription
2.2Ідентифікація та пошук пацієнтаСпівробітник клініки(лікар/рецепція) виконує пошук пацієнта в системі eHealth з метою визначити чи зареєстрований пацієнт в eHealth
2.3Вибір режиму доступуВ залежності від ситуації, користувач обирає режим доступу доступу до даних :
  1. Повний доступ, якщо у поточного лікаря є активна декларація з пацієнтом, або пацієнт згодний її оформити
  2. Розширений доступ, якщо можливо задіяти направлення, або є інша підстава отримання розширеного доступу, підкріплена документом (TBD)
  3. Обмежений доступ - доступ через Patient summary - доступний для всіх лікарів
2.4Пошук декларації У разі вибору режиму повного доступу, відбувається пошук активної декларації між пацієнтом та поточним лікарем
2.5Запропонувати оформити деклараціюУ разі, якщо декларацію не знайдено, співробіник лікарні може запропонувати пацієнту оформити її
2.6Оформлення деклараціїУ випадку, коли пацієнт згоден підписати декларацію, запускається процес підписання декларації, в іншому ж випадку, лікар отримає обмежений доступ до даних, а пацієнт отримає послуги за власний рахунок
2.7Надання доступу через направленняВиконуються дії процесу Отримання дозволу пацієнта на операції з даними у системі E-Health

3. Приклад процесу заповнення даних по візиту в МІС*

*-на діаграмі зображений приклад процесу. ЗОЗ залишає за собою право самостійно визначати послідовність та набір дій, які виконуються на візиті.
Також, МІС залишає за собою право самостійно визначати в який момент виконувати виклики веб-сервісів (одразу після створення об'єкту в МІС, або ж наприкінці візиту)

StepDescription
3.1Визначити чи необхідно створити новий епізод
3.2Створити епізод
3.3Визначити чи необхідно змінити назву епізодуНазва епізоду - це допоміжна характеристика епізоду, яка допомогає лікарю орієнтуватися в списку епізодів
3.4Змінити назву епізоду
3.5Створити візитВізит - це адміністративний об'єкт, необхідний для групування взаємодій
3.6Створити взаємодіюВзаємодія - це основний артефакт візиту. Лікар має обов'язково заповнити причину, діагноз та дію.
У блоці "Діагнози" лікар посилається на нові або попередньо-створені діагнози, вказуючи звязок між ними (основний, супутні, ускладнення). Цей набір діагнозів вважається поточним предметом лікування та автоматично дублюється в блок "Поточні діагнози" епізоду.


В залежності від ситуації, лікар може створити наступні об'єкти:
3.7Заповнити обстеження
3.8Заповнити діагнозиВпродовж взаємодії, лікар може зареєструвати як поточні діагнози, так і історичні. Історичні діагнози, які не є предметом лікування поточного епізоду, не зазначаються в блоці "Діагнози" взаємодії і не буть відображені в історіїї діагнозів епізоду.
3.9Заповнити алергії
3.10Заповнити імунізації
3.11Заповнити оцінки ризиків



3.11Визначити, чи необхідно закрити епізод
3.12Закрити епізод, вказати причину

4. Приклад реєстрації реакції на імунізацію

 

#StepDescription
1Звернення пацієнта з реакцією на імунізаціюПацієнт звернувся зі скаргами. Існує ймовірність, що скарги пов'язані з попередньо проведеною імунізацією.
2Пошук імунізації в ЦК, визначення взаємозв'язку симптомів та імунізаціїЛікар виконує пошук імунізації з метою визначити чи мала місце імунізація останнім часом та чи могла вона стати причиню симптомів пацієнта.
3Створення візитуЛікар створює новий візит
4Створення взаємодії з вказанням причини, діагнозу, діїЛікар реєструє ІСРС2-взаємодію - вказує причину, діагноз та дії, які необхідно виконати за результатами візиту
5Зареєструвати обстеження з посиланням на імунізацію(reaction_on)Лікар реєструє результати виконаних обстеженнь на базі скарг пацієнта, наприклад заміряну температуру, почервоніння шкіри, висипання; та посилається на імунізацію з якою вони пов'язані (поле reaction_on).
6Зареєструвати обстеження без посилання на імунізаціюУ разі, коли обстеження не пов'язані з імунізацією, лікар реєструє їх, залишаючи поле reaction_on не заповненим.
7Результати візиту сформовано в МІСПакет даних взаємодії сформований у МІС та може бути переданий до ЦК, як показано в БП №1
  • No labels