OLD_1. Медичний висновок - створення

Загальний вигляд бізнес процесу

1 Загальний вигляд бізнес процесу
2 Опис валідацій та перевірок
3 Опис сценаріїв закінчення робочого процесу
4 Особливості подання дат по періоду дійсності

https://cawemo.com/share/80bb90b6-efe5-41c7-ba17-3d6dff789dc9

Опис валідацій та перевірок

Підгруппа	Маркер на схемі	Суть перевірки	Додаткова інформація

Підгруппа	Маркер на схемі	Суть перевірки	Додаткова інформація
Валідації специфічні до висновків про народження	EGW1	Переконатись, що не існує іншого медичного висновку, щодо події народження. Пошук серед існуючих мед висновків для валідації має проводитись за наступними критеріями: а) висновок, де атрибут extension.newborn.preperson аналогічний б) стан існуючого висновку в системі відмінний від ENTERED-IN-RROR в) висновок того самого типу (NEWBORN)	Використовується внутрішня база записів медичних висновків, для контролю і упередження випуску дублікатів медичних висновків
	EGW5.1	Перевірити, чи було передано метод авторизації, який буде використаний для надсилання смс.
	EGW5.2	Переконатись, що тип методу авторизації дозволений: "type" => "OTP" з указаним атрибутом `phone_number` АБО “type” => “THIRD_PERSON” з указаним атрибутом `reference.phone_number`
	EGW5.3	Переконатись, що вказаний метод авторизації є активним: "is_active" => true
	EGW5.7	Переконатись, що у медвисновку вказані дата народження та стать дитини (pre-person у `Composition.subject`) Умови, які мають виконуватись значення `gender`та `birth_date` не NULL
	EGW5.8	Перевірка дозволених значень статі для медичного висновку в даній категорії, для субʼєкта focus
	EGW5.9	Перевірка дозволених значень віку для медичного висновку в даній категорії, для субʼєкта subject
	EGW12	Та ж, що і на 5.1
Валідації, що застосовуються до всіх мед-висновків на етапі створення, незалежно від типу	EGW2	Переконатись, що медичний висновок створюється тим самим автором, який створював Encounter Атрибут Encounter.performer.value має бути тим самим, що і Composition.author	відбувається по даним обʼєкту Encounter отриманим з сервісу Medical Events
	EGW3	Переконатись, що медичний висновок дозволено видавати для даного типу і статусу Encounter Умови, які мають виконуватись encounter.status = finished encounter.type згідно сконфігурованих	відбувається по даним обʼєкту Encounter отриманим з сервісу Medical Events
	EGW4	Перевірка, що медичний висновок видається на відповідну послугу Умови, які мають виконуватись encounter.diagnoses.role має відповідати сконфігурованим в сервісі, для діагноза з атрибутом primary	відбувається по даним обʼєкту Encounter отриманим з сервісу Medical Events
	EGW5	Перевірка кваліфікації лікаря Необхідна, тому що кваліфікація лікаря не перевіряється сервісом медичних подій при створенні Encounter, але повина перевірятись при видачі медичних висновків Умови, які мають виконуватись specialities.speciality відповідає сконфігурованому значення для обʼєктів з атрибутом speciality_officio=True	відбувається по даних обʼєкту Employee з сервісу PRM
	EGW5.3	Перевірка, чи вимагається наявність division налаштуваннями системи для даного типу та категорії медвисновку
	EGW5.4	Перевірка наявності інформації про division в Encounter
	EGW5.6	Перевірка активності у системі записів про осіб, вказаних у `Composition.subject` та `Composition.section.focus` Умови, які мають виконуватись параметр is_active == TRUE	відбувається по даних об'єктів person/pre-person із MPI
	EGW6	Перевірка успішності генерації фінального документу з сервісу шаблонів MAN	відбувається по результатам успішності отримання відповіді з сервісу MAN
Валідації, що застосовуються до всіх мед-висновків на етапі підписання, незалежно від типу	EGW7	Процес валідації підписанного обʼєкту документу медичного висновку	відбувається за допомогою сервісу DS, який видає вичерпний статус валідації підпису, як частину відповіді
	EGW8	Перевірка того, чи має користувач системи(напр. лікар) статус, який вказує на добровільну відмову від отримання РНОКПП	відбувається за результатами запису про відсутність РНОКПП у співробітника в базі сервісу PRM (атрибут no_tax_id)
	EGW9	Порівняння даних про номер документу у сервісі PRM(атрибути з порції employee.party.documents) і даними про РНОКПП в сертифікаті підпису отриманий з сервісу DS	відбувається за результатами атрибутів РНОКПП у відповідях сервісів DS і PRM
	EGW10	Порівняння даних про РНОКПП отриманих у відповідь з сервісу DS з даними записів про РНОКПП співробітника у сервісі PRM(дані отримані на етапі створення висновку)	відбувається за результатами атрибутів РНОКПП у відповідях сервісів DS і PRM
	EGW11	Порівняння підписаного КЕП обʼєкту і обʼєкту, що був створений компонентом Медичних висновків на підставі сконфігурованого шаблону і даних.	відбувається за результатами створення Composition.section.div

Опис сценаріїв закінчення робочого процесу

Підгруппа	Назва етапу	Деталі

Підгруппа	Назва етапу	Деталі
Загальна	Успішне закінчення процесу	Випущено і збережено медичний висновок, згідно сконфігурованого шаблону і наданих даних, накладено підпис КЕП лікаря, дані підпису валідовано
Неуспішні закінчення робочого процесу, специфічні для висновків про народження	TE1	Випуск медичного висновку неможливий, бо існує інший дублюючий запис для даного Pre-person ID
	TE5.1	Переданий метод авторизації не відповідає дозволеному типу
	TE5.2	Передано не активний метод авторизації
	TE5.6	Не дозволяється створення медвисновку про народження, оскільки не вказані обов'язкові параметри: дата народження та стать дитини
Неуспішні закінчення робочого процесу створення медичних висновків, однакові для всіх медичних висновків незалежно від типу	TE2	Переданий атрибут автора відмінний від автора обʼєкту Encounter, що не дозволяється правилами створення мед висновків
	TE3	Даний тип Encounter не дозволяється для даного типу медичних висновків
	TE4	Основний діагноз вказаний в Encounter не дозволяється для даного типу медичних висновків АБО в даному Encounter не надано код діагнозу (напр. у випадку коли енкаунтер створюється для Condition, який було створено в минулому)
	TE5	Кваліфікація лікаря вказана в системі не дозволяє випускати медичні висновки такого типу
	TE5.4	Не дозволяється створення медвисновку по Encounter, у якому відсутній елемент `division`, у випадку, якщо згідно налаштувань системи це значення необхідне для даного типу та категорії медвисновків.
	TE5.5	Не дозволяється створення медвисновку, оскільки записи про осіб, вказаних у Composition.subject та Composition.section.focus, мають не активний у системі статус
	TE6	Генерація документу згідно шаблону неуспішна (внутрішня помилка сервісів)
Неуспішні закінчення робочого процесу підписання медичних висновків, однакові для всіх медичних висновків незалежно від типу	TE7	Валідація цифрового підпису накладеного на обʼєкт медичних висновків неуспішна
	TE8	Неуспішна перевірка належності підпису КЕП до автора медичного висновку (неспівпадіння РНОКПП автора)
	TE9	Підписаний обʼєкт не відповідає згенерованому Composition

Особливості подання дат по періоду дійсності

Відповідно, до Технічних Вимог (розділи 3.8.1 та 3.8.2), початок та кінець періоду дійсності МВТН (параметри "event.period.start" та "event.period.end"мають передаватися МІС до ЕСОЗ у форматі ISO 8601 (приклад: "2021-04-06T15:22:53.403Z");

Варто відзначити, що:

1. Z, яке додано одразу після часу, означає, що дата/час передаються у форматі UTC без урахування часової зони (If the time is in UTC, add a Z directly after the time without a space);

2. ЕСОЗ по запиту getComposition віддає дати у тому вигляді, як було отримано на етапі створення МВТН (бо це підписний контент);

3. в інформаційну довідку початок та кінець періоду дійсності МВТН виводяться згідно законів України в часовії зоні України. Тобто, UTC преобразується до Київської часової зони.

Приклад:

введений час "2021-05-27T23:59:00.000Z" є валідним і представляє собою час 2:59 28.05.2021 в Україні.