Бізнес-процес (настанова) (видаліть блок з посиланням перед публікацією документа)
Властивості документа
Загальні відомості
Через помилкове введення відомостей або хибну ідентифікацію пацієнта, медичний працівник (далі - Користувач), що є автором медичного висновку про непрацездатність або медичного висновку про народження (далі - МВ) може скасувати свій медичний висновок та створити замість нього новий МВ.
Передумови
Передумовою створення медичного висновка «на заміну» є попереднє скасування існуючого МВ (який потребує заміни) відповідно до процесів Скасування МВН та Скасування МВТН.
МВ, який потрібно замінити, має бути переданий в явному вигляді в об’єкті relatesTo за наступним правилом:
relatesTo.code = replaces;
relatesTo.targetIdentifier = ідентифікатор скасованого МВ;
Для створюваного МВ "на заміну" тип (параметр "type") має збігатись з типом попереднього медичного висновку, для якого виконується заміна. Решта атрибутів МВ можуть бути змінені, включно з ідентифікаторами пацієнта, непрацездатної особи, періоду дії тощо;
МВ “на заміну“ створюється для останнього в ланцюгу, попередньо скасованого медичного висновку;
При створенні МВ "на заміну" Система перевіряє:
якщо причина скасування попередньо скасованого МВ (параметр "reason.coding.code") з довідників COMPOSITION_CANCELLATION_REASONS_NEWBORN та COMPOSITION_CANCELLATION_REASONS_TEMP_DISABILITY зазначена у конфігураційному параметрі (“EMAL_REPLACEMENT_FLOW_NEWBORN_ALLOWED_CANCELLATION_REASONS” для МВН та “EMAL_REPLACEMENT_FLOW_DISABILITY_ALLOWED_CANCELLATION_REASONS” для МВТН), то Система використовує фільтри EMAL_FILTER_REPLACEMENT_PERIOD_START_NEWBORN і EMAL_FILTER_REPLACEMENT_PERIOD_START_DISABILITY, які конфігурують глибину дати створення МВ "на заміну" в минулому (поточне значення становить 365 днів);
якщо причина скасування попередньо скасованого МВ (параметр "reason.coding.code") з довідників COMPOSITION_CANCELLATION_REASONS_NEWBORN та COMPOSITION_CANCELLATION_REASONS_TEMP_DISABILITY НЕ зазначена в конфігураційному параметрі (“EMAL_REPLACEMENT_FLOW_NEWBORN_ALLOWED_CANCELLATION_REASONS” для МВН та “EMAL_REPLACEMENT_FLOW_DISABILITY_ALLOWED_CANCELLATION_REASONS” для МВТН), то Система використовує фільтри EMAL_FILTER_PERIOD_START_NEWBORN та EMAL_FILTER_PERIOD_START_DISABILITY, які конфігурують глибину дати створення МВ в минулому для загального скасування (поточне значення становить 7 днів).
Схема бізнес-процесу
Зображення схеми
Посилання на схему
На перегляд: https://modeler.cloud.camunda.io/share/54db7826-f6f1-4711-8f8f-4fcb2524b5d2
Похідний файл схеми (BPMN)
Опис кроків по процесу
1 | № кроку | Крок | Опис | Технічний модуль | Методи API які мають або можуть бути використані |
2 | SE 1.10 | Формування МВ на заміну | Виявлено некоректно створений медичний висновок, замість якого є потреба створити новий МВ. | ||
3 | 1.10 | Знайти запис про пацієнта | Користувачем має бути переданий через МІС до ЕСОЗ ідентифікатор пацієнта та ідентифікатор взаємодії, за якою встановлено факт настання медичної непрацездатності. Детальніше в описі процесу BP-ESOZ-022-0001 [MIS] Створення запису про пацієнта. | Scope -person:read. Resource - GET /api/persons.
| Пошук запису про ідентифіковану особу в ЕСОЗ можливий за методом АРІ Search for a Person |
4 | 1.20 | Виконати пошук МВ | Користувач перевіряє наявність раніше створених МВТН через пошук таких МВТН, що описано в процесі BP-ESOZ-018-0008 [MIS] Пошук та отримання даних про медичні висновки. По завершенню дії перейти до кроку GW 1.20 | ||
5 | 1.30 | Скасувати МВ | Користувач здійснює за допомогою МІС скасування знайденого МВ, який необхідно замінити, відповідно до процесу Скасування МВН або Скасування МВТН, залежно від типу медичного висновку. | ||
6 | 1.40 | Вказати скасований МВ | Користувач за допомогою МІС вказує ідентифікатор скасованого МВ в параметрі relatesTo.targetIdentifier із характером зв'язку relatesTo.code = replaces. | ||
7 | 1.50 | Заповнити/ змінити дані МВ "на заміну" | Користувач вручну при створенні МВ на “заміну“ заповнює або вносить зміни до даних відповідно до умов процесів формування нового МВТН або формування нового МВН, залежно від типу медичного висновку. | ||
8 | 1.60 | Виконати запит на створення МВ "на заміну" | МІС виконує запит на створення МВ згідно методу API Системи createComposition. При створенні запиту Система очікує на relatesTo.code який має значення replaces та relatesTo.targetIdentifier з ідентифікатором скасованого МВ. По завершенню дії, перейти до кроку 1.70 | Scope -composition:create. Resource - POST /patients/composition. | [API-006-001-001-0211] |
9 | 2.10 | createComposition | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ. |
| [API-006-001-001-0211] |
10 | 2.20 | Create CREATE_COMPOSITION job | Під час виконання методу АПІ створюється окрема асинхронна задача, яка ставиться в чергу задач. За результатом виконання задачі зі створення Composition, ЕСОЗ віддає через АПІ відповідь, що МВТН успішно створений | ||
11 | 1.70 | Отримати створений МВ | МІС отримує деталі створеного МВ за методом АРІgetComposition. По завершенню виконується крок 1.80. | Scope -composition:read Resource - GET /patients/{patientId}/composition/{compositionId}/episode/{episodeId}/encounter/{encounterId} | [API-006-001-001-0214] |
12 | 2.30 | getComposition | В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ. |
| [API-006-001-001-0214] |
13 | 1.80 | Перевірити дані по створюваному МВ | Користувач здійснює перевірку відомостей про створюваний МВ, що зазначені в інформаційній довідці, та/або інтерфейсі. Зокрема повинні бути перевірені:
| ||
14 | GW 1.10 | Потрібно переглянути друковану форму? | У Користувача є можливість переглянути друковану форму МВТН, щоб надалі виправити помилки.
| ||
15 | 1.90 | Переглянути друковану форму | На вимогу пацієнта Користувач має роздрукувати інформаційну довідку МВТН за процесом Отримання друкованої форми МВ, після чого перейти до кроку GW 1.60. |
| |
16 | GW 1.20 | Помилки в МВ відсутні? |
| ||
17 | 1.100 | Виправити помилки | За наявності помилок в друкованій формі МВТН та/або інтерфейсі, Користувач виправляє такі помилки та переходить на крок 1.40 поточних вимог до процесу. Виправлення помилок здійснюється виключно через створення нового МВ. МІС може автоматично заповнити відповідні поля (атрибути) в новому запиті на створення МВ, щоб медичний працівник мав змогу виправити помилки, допущені у попередньому запиті. | ||
18 | 1.110 | Засвідчити дані КЕП | В разі відсутності помилок у МВ, Користувач повинен мати можливість засвідчити запит на підписання МВ за допомогою КЕП користувача. Після засвідчення КЕП, перейти до кроку 1.120. | ||
19 | 1.120 | Виконати запит на підписання | МІС виконує запит на підписання методом АРІ Системи signComposition із зазначенням в якості параметру ідентифікатора МВТН "composition_id". Далі перейти до кроку 1.190. | Scope -composition:signd Resource - PATCH /patients/composition/{compositionId}/sign | [API-006-001-001-0212] |
20 | |||||
21 | |||||
22 | |||||
23 |
Бізнес правила
Результат процесу
Перелік змін
Версія документа | Опис змін | Номер релізу | |
---|---|---|---|
1 | |||
2 |