ЕСОЗ - публічна документація
RC-Продовження / скорочення МВТН
Загальні ствердження
Медичний працівник, створюючи МВТН, не може (і не має) вказувати дані про продовження, або скорочення;
ЕСОЗ за допомогою пошуку МВТН у зазначеній категорії зазначає ідентифікатор знайденого попереднього висновоку в об'єкті relatesTo;
Медичний працівник може повідомити пацієнта, що знайдено існуючий МВТН. Тож, наступний МВТН може доповнити, або скоротити термін непрацездатності;
Обʼєкт relatesTo завжди генерується Системою, не лікарем! Ідентифікатор у relatesTo.code вказує на характер зв'язку із попереднім МВТН:
– Appends (продовження строку МВТН);
– Replaces (уточнення особи існуючого висновку - тільки якщо попередній МВТН був створений на неідентифікованого пацієнта (pre-person));
– Transforms (скорочення строку МВТН);
Обʼєкт relatesTo генерується на етапі створення чернетки МВТН (STATUS = PRELIMINARY);
Обʼєкт relatesTo для випадків продовження (appends) та скорочення (transforms) генерується Системою за наступних умов:
в обох МВТН зазначено одного і того ж пацієнта (subject);
пов'язані МВТН мають одну і ту саму категорію МВТН (наприклад, SICKNESS);
періоди дії по МВТН стикуються, або пересікаються. Приклад:
період дійсності МВТН 1 | період дійсності МВТН 2 | Результат | relatesTo у МВТН1 |
---|---|---|---|
з 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 відсутній |
якщо медичний працівник при створенні МВТН зазначив IS_FORCE_RENEW = TRUE (на думку лікаря, це новий випадок непрацездатності, а не продовження), то relatesTo не буде сформовано Системою і МВ буде створено як новий.
Схема процесу створення МВТН для продовження / скорочення
https://modeler.cloud.camunda.io/share/caf14657-1443-4d92-9b7e-aebc6817e308
Опис кроків по процесу
№ | Крок | Опис |
---|---|---|
1 | Знайти запис про пацієнта | Медичний працівник знаходить запис про пацієнта. Пошук запису про ідентифіковану особу в ЕСОЗ можливий за методом АРІ Search for a Person. |
2 | Виконати пошук та отримання МВ | За необхідності, перед формуванням запиту на створення МВН медичний працівник перевіряє наявність раніше створених МВН через пошук таких МВ. Пошук здійснюється відповідно до опису процесу Пошук та отримання МВ. |
3 | Створити / обрати взаємодію | Створення ЕМЗ по взаємодії пацієнта відбувається за правилами процесу “Реєстрація результатів візиту в ЦК”. Пошук існуючої взаємодії може бути здійснений із дотриманням вимог по пошуку за методами АРІ: Медичний працівник має бути автором обраної взаємодії (ідентифікатор користувача повинен співпадати з ідентифікатором "Виконавець" ("performer") у взаємодії). |
4 | Визначити непрацездатну особу та МА (метод автентифікації) | Медичний працівник визначає непрацездатну особу, заповнюючи відповідні атрибути МВТН згідно з правилами застосування атрибутів Subject та Focus. Також при формуванні запиту на створення МВТН у випадку вказання ідентифікованого пацієнта як непрацездатної особи (параметр "section.focus") медичний працівник повинен мати змогу обрання методу автентифікації з наявних у непрацездатної особи. Разом із тим, медичний працівник повинен мати можливість не визначати метод автентифікації та не передавати його у запиті на створення МВ. В такому випадку, пацієнт не отримає повідомлення (смс) про створений МВ. |
5 | Заповнити дані по новому МВТН | Медичний працівник заповнює так дані при формуванні запиту на створення МВТН:
значення параметру EMAL_FILTER_PERIOD_START_DISABILITY ігнорується, якщо: 1. в створюваному МВТН зазначено - або категорію PREGNANCY; - або extension.is_foreign_treatment=true 2. при створенні уточнення (preperson -> person) для МВТН
різниця в календарних днях між датою початку початку та датою завершення обмежується параметрами EMAL_FILTER_DISABILITY_SIGNLE_SPAN та EMAL_FILTER_DISABILITY_TOTAL_SPAN, які відображують максимальну довжину періоду призначення або продовження МВТН за категорією.
2. необов'язкові параметри:
|
6 | Виконати запит на створення МВТН | Для створення МВТН медичний працівник повинен виконати запит на створення МВТН згідно методу API Системи ("createComposition"). |
7 | Отримати створений МВТН | Медичний працівник отримує деталі створеного МВТН за методом АРІ getComposition. |
8 | Створити запит на approval | В разі наявності даних у об'єкті relatesTo та якщо медичний працівник не має доступу до деталей МВТН, то він повинен мати змогу створити запит на отримання доступу (до ЕМЗ з метою перегляду пов'язаного МВТН) з боку пацієнта відповідно до опису процесу “Отримання дозволу пацієнта на операції з даними у системі E-Health” В разі відсутності необхідності отримання деталей по існуючому МВТН, або при відсутності згоди на доступ з боку пацієнта, медичний працівник може перейти до наступного кроку, якщо треба продовжити процес по створенню МВТН. |
9 | Отримати деталі з МВТН з relatesTo | Медичний працівник отримує деталі по пов'язаному МВТН за методом АРІ getComposition для ознайомлення з даними висновку. |
10 | Проінформувати пацієнта (за необхідності) | Медичний працівник може повідомити пацієнта, що знайдено існуючий МВТН. Тож, наступний МВТН може доповнити, або скоротити термін непрацездатності. За певних обставин медичний працівник може врахувати можливу відмову пацієнта від продовження процесу по створенню нового МВТН і припинити процес. Наприклад, якщо пацієнт звернувся з тою самою проблемою до декількох різних лікарів з надією на нескінченне продовження лікарняного через створення нового МВТН (шахрайство з боку пацієнта). В іншому випадку медичний працівник переходить до наступного кроку. |
11 | Перевірити дані по створюваному МВТН | Медичний працівник здійснює перевірку відомостей про створюваний МВТН, що зазначені в інформаційній довідці, та/або інтерфейсі. Зокрема повинні бути перевірені:
|
12 | Переглянути інформаційну довідку | Медичний працівник має можливість переглянути інформаційну довідку МВТН за допомогою метода АРІ GetCompositionPrintForm. |
13 | Виправити помилки | При наявності помилок в інформаційній довідці МВТН та/або інтерфейсі, медичний працівник переходить на крок 3 поточних вимог до процесу. Виправлення помилок здійснюється виключно через створення нового МВ. МІС може автоматично заповнити відповідні поля (атрибути) в новому запиті на створення МВ, щоб медичний працівник мав змогу виправити помилки, допущені у попередньому запиті. |
14 | Засвідчити КЕП та виконати запит на підписання | В разі відсутності помилок у відомостях інформаційної довідки та/або інтерфейсі, медичний працівник повинен мати можливість:
|
15 | Отримати результат виконання job | Медичний працівник отримує результати виконання запиту через виконання методу getAsyncJobStatus та за необхідності інформує пацієнта про (не)успішність створення МВТН. |
16 | Роздрукувати МВТН за вимогою | Медичний працівник має можливість переглянути інформаційну довідку МВТН за допомогою метода АРІ GetCompositionPrintForm та на вимогу пацієнта роздрукувати її. |
17 | Переглянути поточний статус/статус обробки МВТН
| Дані по статусу медичний працівник отримує через деталі по статусу обробки МВ за методом АРІ getCompositionProcessingStatus. Медичний працівник за потреби має можливість переглянути такі дані:
|
ЕСОЗ - публічна документація