Бізнес-процес (настанова) (видаліть блок з посиланням перед публікацією документа)
Властивості документа
Загальні відомості
З огляду на те, що стан здоров'я пацієнта може різко змінитись, активний (дійсний) медичний висновок про непрацездатність (далі -МВТН) може бути як продовжений в терміні, так і скорочений, в залежності від прийнятого медичним працівником клінічного рішення.
Передумови
Наявність в Системі успішно зареєстрованого НМП СМД (надавача медичних послуг спеціалізованої медичної допомоги) та доступ до ЕСОЗ медичного працівника з відповідними правами користувача ЕСОЗ (далі - Користувач).
Наявний у системі дійсний МВТН
Користувач, створюючи МВТН, не може (і не має) вказувати дані про продовження, або скорочення;
ЕСОЗ за допомогою пошуку МВТН у зазначеній категорії зазначає ідентифікатор знайденого попереднього висновоку в об'єкті relatesTo;
Користувач може повідомити пацієнта, що знайдено існуючий МВТН. Тож, наступний МВТН може доповнити, або скоротити термін непрацездатності;
Обʼєкт relatesTo у випадку продовження/скорочення МВТН генерується Системою, не лікарем. Ідентифікатор у relatesTo.code вказує на характер зв'язку із попереднім МВТН:
Appends (продовження строку МВТН);
Transforms (скорочення строку МВТН);
Replaces (уточнення особи існуючого висновку (тільки якщо попередній МВТН був створений на неідентифікованого пацієнта (pre-person)) або створення МВТН “на заміну“);
Обʼєкт relatesTo генерується на етапі створення чернетки МВТН (STATUS = PRELIMINARY);
Обʼєкт relatesTo для випадків продовження (appends) та скорочення (transforms) генерується Системою за наступних умов:
в обох МВТН зазначено одного і того ж пацієнта (subject);
пов'язані МВТН мають одну і ту саму категорію МВТН (наприклад, SICKNESS);
періоди дії по МВТН стикуються, або пересікаються.
Якщо Користувач при створенні МВТН зазначив IS_FORCE_RENEW = TRUE (на думку лікаря, це новий випадок непрацездатності, а не продовження), то relatesTo не буде сформовано Системою і МВ буде створено як новий.
Приклад:
Період дійсності МВТН 1 | Період дійсності МВТН 2 | Результат | relatesTo у МВТН2 |
---|---|---|---|
з 01.10 по 05.10 | 03.10 по 15.10 | продовження, бо періоди дії по МВТН пересікаються | code = appends targetIdentifier = МВТН1 |
01.10 по 05.10 | 03.10 по 03.10 | скорочення, бо початк періоду дії МВТН2 знаходиться в межах періоду дії МВНТ1. | code = transforms targetIdentifier = МВТН1 |
01.10 по 05.10 | 05.10 по 10.10 | продовження, бо періоди дії по МВТН стикуються | code = appends targetIdentifier = МВТН1 |
01.10 по 05.10 | 06.10 по 10.10 | продовження, бо періоди дії по МВТН стикуються | code = appends targetIdentifier = МВТН1 |
01.10 по 05.10 | 07.10 по 10.10 | Висновки не пов'язані одним випадком непрацездатності. Періоди дії МВТН1 та МВТН2 мають розрив більше, ніж на 1 день. Продовження не буде, relatesTo у МВТН1 | блок relatesTo у МВТН1 відсутній |
Схема бізнес-процесу
Зображення схеми
Посилання на схему
На перегляд: https://modeler.cloud.camunda.io/share/142bf49d-e397-472b-8ca0-21f31c792c5c
На редагування: https://modeler.cloud.camunda.io/diagrams/b114820d-9d98-4e6c-9b29-deccdbf0fec4--bp-esoz-018-0002-mis-продовження-скорочення-мвтн?v=5320,409,1
Похідний файл схеми (BPMN)
Опис кроків по процесу
1 | № кроку | Крок | Опис | Технічний модуль | Методи API які мають або можуть бути використані |
2 | SE 1.10 | Продовження або скорочення МВТН | Потреба змінити (продовжити або скоротити) період тривалості МВТН. | ||
3 | 1.10 | Ідентифікація пацієнта | Медпрацівник (Користувач) ідентифікує пацієнта поза системою для подальшого пошуку інформації по пацієнту в ЕСОЗ. |
| |
4 | 1.20 | Знайти запис про пацієнта | Для продовження або скорочення МВТН Користувачем має бути переданий через МІС до ЕСОЗ ідентифікатор пацієнта та ідентифікатор взаємодії, за якою встановлено факт настання медичної непрацездатності. | Scope -person:read. Resource - GET /api/persons. | Пошук запису про ідентифіковану особу в ЕСОЗ можливий за методом АРІ Search for a Person. |
5 | GW 1.10 | Продовжити без пошуку існуючого МВТН? |
| ||
6 | 1.30 | Виконати пошук та отримання медвисновку | Користувач перевіряє наявність раніше створених МВТН через пошук таких МВТН, що описано в процесі BP-ESOZ-018-0008 [MIS] Пошук та отримання даних про медичні висновки. По завершенню дії перейти до кроку GW 1.20 | Scope -composition:search. Resource - GET /patients/{patientId}/composition. | |
7 | GW 1.20 | Знайдено МВТН? |
| ||
8 | EE 1.10 | МВТН не знайдено | МВТН не знайдено, вихід із процесу. | ||
9 | 1.40 | Створити / обрати епізод та взаємодію | Створення ЕМЗ по взаємодії пацієнта відбувається за правилами процесу “Реєстрація результатів візиту в ЦК”. Користувач (медичний працівник) має бути автором обраної взаємодії (ідентифікатор користувача повинен співпадати з ідентифікатором "Виконавець" ("performer") у взаємодії). | Scope -encounter:read. Resource -GET /api/patients/{{patient_id}}/encounters/{{encounter_id}} Scope -patient_summary:read. Resource -GET /api/patients/{{patient_id}}/summary/episodes. | Пошук існуючої взаємодії може бути здійснений із дотриманням вимог по пошуку за методами АРІ: |
10 | 1.50 | Визначити непрацездатну особу | Користувач визначає непрацездатну особу, заповнюючи відповідні атрибути МВТН згідно з правилами застосування атрибутів Subject та Focus. Також при формуванні запиту на створення МВТН у випадку вказання ідентифікованого пацієнта як непрацездатної особи (параметр "section.focus") Користувач повинен мати змогу обрання методу автентифікації з наявних у непрацездатної особи. Разом із тим, Користувач повинен мати можливість не визначати метод автентифікації та не передавати його у запиті на створення медвисновку. В такому випадку, пацієнт не отримає повідомлення (sms) про створений медвисновок. По завершенню виконання дії, перейти до GW 1.30. | ||
11 | GW 1.30 | Чи потрібно вказувати метод автентифікації? |
| ||
12 | 1.60 | Створити/обрати метод автентифікації непрацездатної особи | На цьому кроці Користувач вказує метод автентифікації непрацездатної особи, описаний в процесі BP-ESOZ-020-0003 [MIS] Отримання даних методів автентифікації пацієнта. По завершенню виконання дії, перейти до GW 1.40. |
| |
13 | GW 1.40 | Чи вказано метод МА? |
| ||
14 | 1.70 | Інформаційне повідомлення про відсутність МА | Користувач отримує інформаційне повідомлення (MSG-0006) про відсутність МА та переходить до кроку 1.80. | ||
15 | 1.80 | Заповнити дані по новому МВТН | Користувач заповнює такі дані при формуванні запиту на створення МВТН:
Можливість застосування extensions в залежності від категорії МВ):
Далі перейти до кроку GW 1.50. | ||
16 | GW 1.50 | Це новий випадок непрацездатності, не пов'язаний із попередніми випадками (чи встановлено ознаку isForceRenew == TRUE)? |
| ||
17 | 1.90 | Створення та підписання нового МВТН | Користувач може створити та підписати новий МВТН за процесом BP-ESOZ-018-0001 [MIS] Формування нового МВТН. Далі перейти до кроку ЕЕ 1.20. |
| |
18 | ЕЕ 1.20 | Продовження або скорочення МВТН не виконано | Продовження або скорочення МВТН не виконано, вихід з процесу. | ||
19 | 1.100 | Виконати запит на створення МВТН | Для створення МВТН Користувач повинен виконати запит на створення МВТН згідно методу API Системи createComposition. Далі перейти до кроку 1.110. | Scope -composition:create. Resource - POST /patients/composition. | [API-006-001-001-0211] |
20 | 2.10 | createComposition | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ. |
| [API-006-001-001-0211] |
21 | 2.20 | Create CREATE_COMPOSITION job | Під час виконання методу API створюється окрема асинхронна задача, яка ставиться в чергу задач. За результатом виконання задачі зі створення Composition, ЕСОЗ віддає через API відповідь, що МВТН успішно створений | ||
22 | 1.110 | Отримати результат виконання (job) | На цьому кроці МІС отримує результати опрацювання запиту щодо створення МВТН в ЦБД ЕСОЗ. Далі переходе до кроку GW 1.60. | Scope -composition:read Resource - GET /patients/{patientId}/composition/{compositionId}/episode/{episodeId}/encounter/{encounterId} | [API-006-001-001-0209] |
23 | 2.30 | getAsyncJobStatus | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ. |
| [API-006-001-001-0209] |
24 | GW 1.60 | МВТН створено? |
| ||
25 | 1.120 | Переглянути результати створення МВТН | У Користувача є можливість отримати результати створення МВТН. Далі перейти до кроку ЕЕ 1.30. | ||
26 | ЕЕ 1.30 | МВТН не створено | МВТН не створено та вихід з процесу. | ||
27 | 1.130 | Отримати створений МВТН | Користувач отримує деталі створеного МВТН за методом АРІgetComposition. Далі перейти до кроку GW 1.70 | Scope -composition:read Resource - GET /patients/{patientId}/composition/{compositionId}/episode/{episodeId}/encounter/{encounterId} | [API-006-001-001-0214] |
28 | 2.40 | getComposition | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ. |
| [API-006-001-001-0214] |
29 | GW 1.70 | Чи треба переглянути МВТН, вказаний в relatesTo |
| ||
30 | GW 1.80 | Є доступ до МВТН? |
| ||
31 | 1.140 | Виконати пошук МВТН з relatesTo для отримання ID контексту | Користувач за допомогою пошуку МВТН у заданій категорії зазначає ідентифікатор знайденого попереднього висновоку в об'єкті relatesTo | Scope -composition:search. Resource - GET /patients/{patientId}/composition. | [API-006-001-001-0215] |
32 | 2.50 | searchComposition | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ | [API-006-001-001-0215] | |
33 | 1.150 | Створити запит на approval для контексту | В разі наявності даних у об'єкті relatesTo та якщо Користувач не має доступу до деталей МВТН, то він повинен мати змогу створити запит на отримання доступу (до ЕМЗ з метою перегляду пов'язаного МВТН) з боку пацієнта відповідно до опису процесу “Отримання дозволу пацієнта на операції з даними у системі E-Health” В разі відсутності необхідності отримання деталей по існуючому МВТН або за відсутності згоди на доступ з боку пацієнта, Користувач може перейти до наступного кроку, якщо треба продовжити процес по створенню МВТН. | ||
34 | GW 1.90 | Чи отримано доступ? |
| ||
35 | 1.160 | Отримати деталі МВТН з relatesTo | Користувач отримує деталі по пов'язаному МВТН за методом АРІgetComposition для ознайомлення з даними висновку. | Scope -composition:read Resource - GET /patients/{patientId}/composition/{compositionId}/episode/{episodeId}/encounter/{encounterId} | [API-006-001-001-0214] |
36 | 2.60 | getComposition | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ. |
| [API-006-001-001-0214] |
37 | 1.170 | Проінформувати пацієнта (за необхідності) | Користувач може повідомити пацієнта, що знайдено існуючий МВТН. Тож, наступний МВТН може доповнити або скоротити термін непрацездатності. За певних обставин Користувач може врахувати можливу відмову пацієнта від продовження процесу по створенню нового МВТН і припинити процес. Наприклад, якщо пацієнт звернувся з тою самою проблемою до декількох різних лікарів з надією на нескінченне продовження лікарняного через створення нового МВТН (шахрайство з боку пацієнта). В іншому випадку Користувач переходить до наступного кроку. | ||
38 | 1.180 | Перегляд медзаписів | Користувач переглядає медичні записи. | ||
39 | GW 1.130 | Це новий випадок непрацездатності, не пов'язаний із попередніми випадками (чи потрібна ознака isForceRenew == TRUE)? |
| ||
40 | 1.190 | Створення та підписання нового МВТН | Потребує переходу на інший процес - BP-ESOZ-018-0001 [MIS] Формування нового МВТН |
| |
41 | EE 1.40 | Продовження або скорочення МВТН не виконано | Продовження або скорочення МВТН не виконано, вихід з процесу. | ||
42 | 1.200 | Перевірити дані по створюваному МВТН | Користувач здійснює перевірку відомостей про створюваний МВТН, що зазначені в інформаційній довідці, та/або інтерфейсі. Зокрема повинні бути перевірені:
| ||
43 | GW 1.100 | Потрібно переглянути друковану форму? |
| ||
44 | 1.210 | Переглянути друковану форму | На вимогу пацієнта Користувач має роздрукувати інформаційну довідку МВТН відповідно до процесу BP-ESOZ-018-0013 [MIS] Отримання друкованої форми МВ. | ||
45 | GW 1.110 | Помилки в МВТН відсутні? |
| ||
46 | 1.220 | Виправити помилки | За наявності помилок в інформаційній довідці МВТН та/або інтерфейсі, Користувач переходить на крок GW 1.120 для подальшого визначення шляху виправлення таких помилок. Виправлення помилок здійснюється виключно через створення нового медвисновку. МІС може автоматично заповнити відповідні поля (атрибути) в новому запиті на створення медвисновку, щоб Користувач мав змогу виправити помилки, допущені у попередньому запиті. | ||
47 | GW 1.120 | Вибір шляху виправлення відповідно до помилки | Якщо потрібно виправити помилку, можна обрати один або декілька з наступних варіантів подій (Inclusive Gateway):
| ||
48 | 1.230 | Засвідчити дані КЕП | В разі відсутності помилок у МВТН, Користувач повинен мати можливість засвідчити запит на підписання МВТН за допомогою КЕП користувача. Після засвідчення КЕП, перейти до кроку 1.240. | ||
49 | 1.240 | Виконати запит на підписання | МІС виконує запит на підписання методом АРІ Системи signComposition із зазначенням в якості параметру ідентифікатора МВТН "composition_id". Далі перейти до кроку 1.190. | Scope -composition:signd Resource - PATCH /patients/composition/{compositionId}/sign | [API-006-001-001-0212] |
50 | 2.70 | SignComposition | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ |
| [API-006-001-001-0212] |
51 | 2.80 | Create SIGN_COMPOSITION job | Під час виконання методу API створюється окрема асинхронна задача, яка ставиться в чергу задач. За результатом виконання задачі із підписання Composition, ЕСОЗ віддає через API відповідь, що МВ успішно підписаний | ||
52 | 1.250 | Отримати результат виконання job | МІС отримує результати виконання запиту через виконання методу getAsyncJobStatus та за необхідності інформує пацієнта про (не)успішність створення МВТН, після чого переходить до кроку GW 1.140. | Scope -composition:read Resource - GET /patients/{patientId}/composition/{compositionId}/episode/{episodeId}/encounter/{encounterId} | [API-006-001-001-0209] |
53 | 2.90 | getAsyncJobStatus | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ, в результаті яких МІС отримує статус задачі |
| [API-006-001-001-0209] |
54 | GW 1.140 | Чи підписано МВТН? |
| ||
55 | ЕЕ 1.50 | МВТН не створено | Продовження або скорочення МВТН не виконано, вихід з процесу. | ||
56 | GW 1.150 | Потрібно переглянути друковану форму? |
| ||
57 | 1.260 | Роздрукувати МВТН за вимогою | На вимогу пацієнта, Користувач має роздрукувати інформаційну довідку МВТН відповідно до процесу BP-ESOZ-018-0013 [MIS] Отримання друкованої форми МВ, після чого переходить до кроку GW 1.160. | ||
58 | GW 1.160 | Переглянути статус обробки МВТН з зовнішними системами? |
| ||
59 | 1.270 | Переглянути статус обробки МВТН з зовнішними системами | Користувач може переглянути статус обробки МВТН, що описаний в процесі BP-ESOZ-018-0005 [MIS] Отримання даних про інтеграційний статус медичних висновків. Після виконаної дії перейти до кроку GW 1.170. | ||
60 | GW 1.170 | Чи потрібно перевідправити в ЕРЛН? |
| ||
61 | 1.280 | Перевідправка МВТН в ЕРЛН | Перевідправка в ЕРЛН реалізовується за окремим процесом BP-ESOZ-018-0006 [MIS] Повторна відправка МВТН в ЕРЛН. Після цього кроку необхідно повернутися до кроку GW 1.160. | ||
62 | ЕЕ 1.60 | МВТН створено та підписано | МВТН створений та підписаний. Завершення процесу. |
Бізнес правила
Доступ до контенту медвисновку регламентується правами на перегляд даних, створених від батьківської сутності, до якої користувач має відповідні права доступу.
Результат процесу
Медичний працівник скоротив або продовжив МВТН.
Перелік змін
Версія документа | Опис змін | Номер релізу | |
---|---|---|---|
1 | |||
2 |