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

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 11 Next »

Бізнес-процес (настанова) (видаліть блок з посиланням перед публікацією документа)

Властивості документа

Тип документа

Бізнес-процес

Назва документа

BP-ESOZ-018-0011 [MIS] Формування МВ на заміну

ID настанови

GUI-004

Автор

Mariana Veremeieva (UA SoE eHealth)

Версія документа

v010

Статус документа

DRAFT

Дата створення

28.06.2024

Дата оновлення

ID групи

BPG-ESOZ-018

ID бізнес-процесу

BP-ESOZ-018-0011

Назва бізнес-процесу

[MIS] Формування МВ на заміну

Посилання на схеми

BP-ESOZ-018-0011 [MIS] Формування МВ на заміну

Загальні відомості

У разі хибної ідентифікації пацієнта, медичний працівник (далі - Користувач), що є автором медичного висновку про непрацездатність або медичного висновку про народження (далі - МВ) може скасувати свій медичний висновок та створити замість нього новий МВ.

Передумови

Передумовою створення медичного висновка «на заміну» є попереднє скасування існуючого МВ (який потребує заміни) відповідно до процесів [DRAFT] BP-ESOZ-018-0012 [MIS] Скасування МВН та [DRAFT] BP-ESOZ-018-0009 [MIS] Скасування МВТН .

  • МВ, який потрібно замінити, має бути переданий в явному вигляді в об’єкті 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

На редагування https://modeler.cloud.camunda.io/diagrams/7a9cf99e-a6a4-4a4b-a01f-17abd297a293--bp-esoz-018-0011-mis-формування-мв-на-заміну?v=640,405,1

Похідний файл схеми (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 [API-010-001-003-0360]

4

1.20

Виконати пошук МВ

Користувач перевіряє наявність раніше створених МВТН через пошук таких МВТН, що описано в процесі BP-ESOZ-018-0008 [MIS] Пошук та отримання даних про медичні висновки.

По завершенню дії перейти до кроку GW 1.20

5

1.30

Скасувати МВ

Користувач здійснює за допомогою МІС скасування знайденого МВ,  який необхідно замінити, відповідно до процесу [DRAFT] BP-ESOZ-018-0012 [MIS] Скасування МВН або [DRAFT] BP-ESOZ-018-0009 [MIS] Скасування МВТН , залежно від типу медичного висновку.

6

1.40

Вказати скасований МВ

Користувач за допомогою МІС вказує ідентифікатор скасованого МВ в параметрі relatesTo.targetIdentifier із характером зв'язку relatesTo.code = replaces.

7

1.50

Заповнити/ змінити дані МВ "на заміну"

Користувач вручну при створенні МВ на “заміну“ заповнює або вносить зміни до даних відповідно до умов процесів [DRAFT] BP-ESOZ-018-0001 [MIS] Формування нового МВТН або [DRAFT] BP-ESOZ-018-0004 [MIS] Формування нового МВН , залежно від типу медичного висновку.

8

1.60

Виконати запит на створення МВ "на заміну"

МІС виконує запит на створення МВ згідно методу API Системи createComposition. При створенні запиту Система очікує на relatesTo.code який має значення replaces та relatesTo.targetIdentifier з ідентифікатором скасованого МВ.

По завершенню дії, перейти до кроку 1.70

 Scope -composition:create.

Resource - POST /patients/composition.

[DRAFT] REST API createComposition [API-006-001-001-0211]

9

2.10

createComposition

В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ.

 

[DRAFT] REST API createComposition [API-006-001-001-0211]

10

2.20

Create CREATE_COMPOSITION job

Під час виконання методу API створюється окрема асинхронна задача, яка ставиться в чергу задач. За результатом виконання задачі зі створення Composition, ЕСОЗ віддає через API відповідь, що МВТН успішно створений

11

1.70

Отримати створений МВ

МІС отримує деталі створеного МВ за методом АРІgetComposition. По завершенню виконується крок 1.80.

Scope -composition:read

Resource - GET /patients/{patientId}/composition/{compositionId}/episode/{episodeId}/encounter/{encounterId}

[DRAFT] REST API getComposition [API-006-001-001-0214]

12

2.30

getComposition

В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ.

 

[DRAFT] REST API getComposition [API-006-001-001-0214]

13

1.80

Перевірити дані по створюваному МВ

Користувач здійснює перевірку відомостей про створюваний МВ, що зазначені в інформаційній довідці, та/або інтерфейсі. Зокрема повинні бути перевірені:

  • тип МВН (параметр "type");

  • категорію МВН (параметр "category");

  • термін дії медичного висновку:

    • початок періоду дійсності (параметр "event.period.start");

    • кінець періоду дійсності МВ (параметр "event.period.end");

  • ідентифікатор обраного методу автентифікації, якщо його було зазначено на кроці 5 (параметр "extension.valueCode.authorize_with").

  • параметр "composition.subject":

    • для МВН це новонароджена дитина;

    • для МВТН це пацієнт;

  • параметр "composition.section.focus":

    • для МВН це жінка, що народила;

    • для МВТН це непрацездатна особа;

  • ідентифікатор взаємодії (параметр "encounter"):

    • для МВН це взаємодія по новонародженій дитині;

    • для МВТН це взаємодія по визначенню проблеми пацієнта;

  • НМП, в якому створено МВ (параметр "custodian");

  • додаткову інформацію з розширених даних (блок "extension") за наявності;

  • тип посилання “replaces“ на пов’язаний МВ (параметр "relatesTo.code");

  • ідентифікатор попередньо скасованого МВ (параметр "relatesTo.targetIdentifier").

14

GW 1.10

Потрібно переглянути друковану форму?

У Користувача є можливість переглянути друковану форму МВТН, щоб надалі виправити помилки.

  • Якщо так (потрібно переглянути друковану форму та/або роздрукувати), то перейти на крок 1.90.

  • Якщо ні (не потрібно переглядати друковану форму), то перейти до кроку GW 1.20.

15

1.90

Переглянути друковану форму

На вимогу пацієнта Користувач має роздрукувати інформаційну довідку МВТН за процесом [DRAFT] BP-ESOZ-018-0013 [MIS] Отримання друкованої форми МВ , після чого перейти до кроку GW 1.60.

 

16

GW 1.20

Помилки в МВ відсутні?

  • Якщо так (помилки відсутні), то перейти до кроку 1.110.

  • Якщо ні (помилки знайдені), перейти до кроку 1.100.

17

1.100

Виправити помилки

За наявності помилок в друкованій формі МВТН та/або інтерфейсі, Користувач виправляє такі помилки та переходить на крок 1.40 поточних вимог до процесу. 

Виправлення помилок здійснюється виключно через створення нового МВ. МІС може автоматично заповнити відповідні поля (атрибути) в новому запиті на створення МВ, щоб медичний працівник мав змогу виправити помилки, допущені у попередньому запиті. 

18

1.110

Засвідчити дані КЕП

В разі відсутності помилок у МВ, Користувач повинен мати можливість засвідчити запит на підписання МВ за допомогою КЕП користувача. Після засвідчення КЕП, перейти до кроку 1.120.

19

1.120

Виконати запит на підписання

МІС виконує запит на підписання методом АРІ Системи signComposition із зазначенням в якості параметру ідентифікатора МВТН "composition_id". Далі перейти до кроку 1.130.

 Scope -composition:signd

Resource - PATCH /patients/composition/{compositionId}/sign

[DRAFT] REST API signComposition [API-006-001-001-0212]

20

2.40

SignComposition

В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ.

 

[DRAFT] REST API signComposition [API-006-001-001-0212]

21

2.50

Create SIGN_COMPOSITION job

Під час виконання методу API створюється окрема асинхронна задача, яка ставиться в чергу задач. За результатом виконання задачі із підписання Composition, ЕСОЗ віддає через API відповідь, що МВ успішно підписаний.

22

1.130

Отримати результат виконання (job)

МІС отримує результати виконання запиту через виконання методу getAsyncJobStatus та за необхідності інформує пацієнта про (не)успішність створення МВТН, після чого переходить до кроку GW 1.30.

 Scope -composition:read

Resource - GET /patients/{patientId}/composition/{compositionId}/episode/{episodeId}/encounter/{encounterId}

[DRAFT] REST API getAsyncJobStatus [API-006-001-001-0209]

23

2.60

getAsyncJobStatus

В ЦБД ЕСОЗ виконуються дії, передбачені відповідним методом АРІ.

 

[DRAFT] REST API getAsyncJobStatus [API-006-001-001-0209]

24

GW 1.30

Чи підписано МВ?

  • Якщо так (МВ підписаний), перейти до кроку GW 1.40.

  • Якщо ні (МВ не підписаний), то перейти до кроку EE 1.10.

25

ЕЕ 1.10

МВ "на заміну" не створено

МВ "на заміну" не створено. Вихід із процесу.

26

GW 1.40

Чи потрібно роздрукувати МВ?

  • Якщо так (потрібно переглянути друковану форму), то перейти до кроку 1.140.

  • Якщо ні (не потрібно переглядати друковану форму), тоді перейти до кроку GW 1.50.

27

1.140

Роздрукувати МВ за вимогою

На вимогу пацієнта, Користувач має роздрукувати інформаційну довідку МВ відповідно до процесу BP-ESOZ-018-0013 [MIS] Отримання друкованої форми МВ, після чого переходить до кроку GW 1.50.

28

GW 1.50

Чи потрібно переглянути статус обробки МВ із зовнішними системами?

  • Якщо так (потрібно переглянути поточний статус МВ із зовнішніми системами), то перейти до кроку 1.150.

  • Якщо ні (не потрібно переглядати МВ), то перейти до кроку EE 1.20.

29

1.150

Переглянути статус обробки МВ із зовнішними системами

Дані по статусу Користувач отримує через деталі по статусу обробки МВ, деталі по отриманню якого описані в процесі BP-ESOZ-018-0005 [MIS] Отримання даних про інтеграційний статус медичних висновків.

По завершенні перейти до кроку EE 1.20.

30

EE 1.20

МВ "на заміну" створено та підписано

МВ "на заміну" створено та підписано. Завершення процесу.

Бізнес правила

  • Доступ до контенту медвисновку регламентується правами на перегляд даних, створених від батьківської сутності, до якої користувач має відповідні права доступу.

  • /wiki/spaces/emal/pages/16906977281

Результат процесу

Перелік змін

Версія документа

Опис змін

Номер релізу

1

2

  • No labels