...
Page Properties | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Загальні відомості
Передумови
Медичний працівник, створюючи МВТН, не може (і не має) вказувати дані про продовження, або скорочення;
ЕСОЗ за допомогою пошуку МВТН у зазначеній категорії зазначає ідентифікатор знайденого попереднього висновоку в об'єкті relatesTo;
Медичний працівник може повідомити пацієнта, що знайдено існуючий МВТН. Тож, наступний МВТН може доповнити, або скоротити термін непрацездатності;
Обʼєкт relatesTo у випадку продовження/скорочення МВТН генерується Системою, не лікарем. Ідентифікатор у relatesTo.code вказує на характер зв'язку із попереднім МВТН:
– Appends (продовження строку МВТН);
– Transforms (скорочення строку МВТН);
– Replaces (уточнення особи існуючого висновку (тільки якщо попередній МВТН був створений на неідентифікованого пацієнта (pre-person)) або створення МВТН “на заміну“);
Обʼєкт relatesTo генерується на етапі створення чернетки МВТН (STATUS = PRELIMINARY);
Обʼєкт relatesTo для випадків продовження (appends) та скорочення (transforms) генерується Системою за наступних умов:
в обох МВТН зазначено одного і того ж пацієнта (subject);
пов'язані МВТН мають одну і ту саму категорію МВТН (наприклад, SICKNESS);
періоди дії по МВТН стикуються, або пересікаються. Приклад:
Якщо медичний працівник при створенні МВТН зазначив IS_FORCE_RENEW = TRUE (на думку лікаря, це новий випадок непрацездатності, а не продовження), то relatesTo не буде сформовано Системою і МВ буде створено як новий.
Схема бізнес-процесу
Зображення схеми
...