| Table of Contents |
|---|
1. Dictionaries
Додається новий класифікатор МКФ (НК 030:2022), що реалізується у вигляді довідників:
...
Content-Type:application/json
Приклад довідників
| Expand | |||||
|---|---|---|---|---|---|
|
2. Episode of care
Тип епізоду реабілітаційної допомоги фіксується у атрибуті Type == REHAB: "Реабілітація" (існуюче значення з довідника eHealth/episode_types) ;
3. Encounter
Додано новий атрибут period для послідовной заміни раніше використованого атрибута date з метою розширення моделі даних відповідно до FHIR v 4.3.0 із вимогою по обов’язковому заповненню period.start та period.end під час внесення даних сутності Encounter у складі ЕМЗ реабілітаційного цикла. Для існуючих у ЕСОЗ записів про взаємодію проводиться міграція даних з встановленням значень period.start == date та period.end == date;
Увага ! Використання атрибута encounter.period відстрочено до введення в дію ТВ v.26 та до того часу заборонено до використання у інтерфейсі МІС-ів !Атрибут date тимчасово залишається у складі для забезпечення зворотньої сумісності, але в майбутньому буде виключений зі складу атрибутів Encounter;
Поточна модель статусів сутності Encounter залишається без змін (finished | entered-in-error).
4. Observation
Сутність Observation використовується у складі Encounter data package первісного, проміжного та заключного обстеження пацієнта для фіксації значень категорійного профіля стану пацієнта відповідно до стандартів класифікації МКФ (НК 030:2022 Класифікатор функціонування, обмеження життєдіяльності та здоров'я);
Для фіксації кожного значення кода МКФ у складі Encounter data package створюється окремий екземпляр сутності Observation для можливості адресного посилання під час планування майбутніх реабілітаційних процедур з відповідних сутностей Activity та Service Request.
Визначений реабілітаційний стан формується парою значень “Категорія з довідника НК 030-2022” (що фіксується у атрибуті code, значення з довідника eHealth/ICF/classifiers), та “Кваліфікатор стану з довідника НК 030-2022” (що фіксується у атрибуті component, значеннями з довідника eHealth/ICF/qualifiers);
Додаткова інформація щодо проведеного обстеження, яка може бути потрібна для формування опису стану пацієнта та рекомендацій по плануванню його реабілітаційного цикла, розміщується у атрибуті comment кожного екземпляра сутності Observation.
Приклад запиту
| Expand | |||||
|---|---|---|---|---|---|
|
5. Care_plan
Care Plan в стаціонарі створюється без СМС-інформування про це пацієнта;
Cтворення Care Plan для амбулаторного виконання реабілітаційних процедур супроводжується стандартним процесом отримання СМС-повідомлення;
Для спрощення механізма отримання доступа до ЕМЗ реабілітаційного цикла сутності Care Plan та Activity додано до переліку сутностей, на які розповсюджується правило доступа “ABAC Rule: @rule_2” - “Співробітник може читати сутність, створену в MSP працівника”;
При створенні Care Plan під час реабілітації у стаціонарі (з "terms_of_service" = "inpatient") прибрано необхідність отримувати підтвердження від пацієнта на таке створення;
Лікар ФРМ може зробити посилання на попередній CarePlan лише у випадку, якщо попередній CarePlan має один із статусів: COMPLETED, ACTIVE, TERMINATED;
Текстова інформація щодо планування поточного реабілітаційного цикла, яка може бути потрібна для формування опису стану пацієнта та рекомендацій по плануванню його реабілітаційного цикла, розміщується у атрибуті note сутності Care Plan.
Інформація по необхідності використання допоміжних засобів реабілітації в межах реабілітаційного цикла додається у якості текстового опису. В описі використовуються значення з нового довідника ISO 9999:2016 без можливості деталізації номенклатури допоміжних засобів. В разі відсутності потреби у ДЗР, вони не зазначаються у CarePlan.note. Якщо потреба в фіксації такої інформації виникає під час планування активностей плана лікування, то можливо внесення текстового опису безпосередньо у атрибут activity.description ;
Зазначення фактично використаних допоміжних засобів при наданні реабілітаційних послуг виконується в рамках формування звітного Encounter data package у атрибуті Procedure.usedCode, який дозволяє використання масиву значень. В разі відсутності факту використання ДЗР, користувач не формує масив Procedure.usedCode;
До складу атрибутів додано обов’язковий атрибут managing_organization для фіксації MSP, який відповідальний за ведення реабілітаційного цикла.
6. Care_plan_activity
Для спрощення механізма отримання доступа до ЕМЗ реабілітаційного цикла сутності Care Plan та Activity додано до переліку сутностей, на які розповсюджується правило доступа “ABAC Rule: @rule_2” - “Співробітник може читати сутність, створену в MSP працівника”;
Реєстрація усіх реабілітаційних послуг виконується у хвилинах— одиницях виміру часу наданої послуги. Це стосується атрибутів quantity, daily_amount та remaining_quantity. Валідація по відповідності одиниці виміру відпрацьовується по правилам:If $.detail.kind=service_request:
Check that $.detail.quantity.system field’s value is SERVICE_UNIT.
Return 422 ('value is not allowed in enum')
Check the $.detail.quantity.code = MINUTE If care plan category is class_23, class_24 or class_25
Return 422 ('Code field of quantity object should be in MINUTE for care plan’s category <category code>')
Запити на створення активності обов’язково пов’язуються з відповідними Observations у первісному, так і у проміжному/заключному обстеженні реабілітаційного цикла, при чому активність наступного цикла може пов’язуватися з обстеженнями попереднього цикла поточного епізода ІРП. У запиті на створення активності користувач передає посилання на масив observation (з code.system =ICF) в параметрі activity.reason_reference, у ньому зазначаються ті посилання на реабілітаційні стани МКФ, по яких планується надання реабілітаційних послуг за створюваною активністю;
Встановлено алгоритм фіксації значення activity.remaining_quantity для можливості автоматичного розрахунку залишкової кількості (об’єму) реабілітаційних послуг із наступними вимогами:
при створенні активності activity.remaining_quantity = activity.quantity;
при створенні в Системі ServiceRequest, у якого фіксується атрибут based_on посилання на поточну активність, Система автоматично зменшує activity.remaining_quantity на кількість, що вказана у параметрі ServiceRequest.quantity.value;
Запланувати активність може лише employee з того MSP, у якому створено поточний Care Plan реабілітаційного циклу (контроль відбувається по атрибуту care_plan.managing_organization);
7. Service Request
Створення Service Request в стаціонарі відбувається без зазначення медичної програми;
Зміни в Service Request Status Model:
використання статусу In_QUEUE в моделі Program Processing statuses стає не обов’язковим. З часом цей статус буде видалено, замінено на IN_PROGRESS.До Service Request data model додається новий атрибут quantity, Тип — Simple.quantity, у якому вказується кількість реабілітаційних процедур, що повинна бути надана за направленням. Для послуг реабілітації service_request.quantity повинен мати одиницю виміру “хвилини” (див. вимоги до атрибуту activity.quantity).
До Service Request data model додається новий атрибут remaining_quantity, Тип — Simple.quantity, В якому автоматично розраховується поточний залишок кількість реабілітаційних процедур, що повинна бути надана за направленням. Для послуг реабілітації service_request.remaining_quantity має одиницю виміру “хвилини”.
До Service Request data model додаються нові атрибути used_by_legal_entity_history та used_by_employee_history, що заповнюються на боці ЕСОЗ автоматично.
8. Procedure
До Procedure data model додається новий атрибут performed_period, Тип — Period, у якому вказується дата-час початку та кінця періоду надання реабілітаційної процедури (по яких автоматично фіксується звітний обсяг проведеної процедури у хвилинах), що повинна бути надана за направленням. По наданим даним коригується значення відповідного service_request.remaining_quantity;
До Procedure data model додається новий атрибут used_code, Тип — масив кодів, у якому вказується масив кодів допоміжних засобів реабілітації з довідника ISO 9999ДЗР (
eHealth/assistive_products), які були використані під час надання реабілітаційної процедури.
Приклад запиту
| Expand |
|---|
{ |
...