D050. Реабілітація. Перелік змін в ЦБД ЕСОЗ

1. Dictionaries

1. Додається новий класифікатор МКФ (НК 030:2022), що реалізується у вигляді довідників:

• eHealth/ICF/classifiers – перелік КЛАСИФІКАТОРІВ МКФ;

• eHealth/ICF/qualifiers – перелік КВАЛІФІКАТОРІВ МКФ;

• eHealth/ICF/qualifiers/extent_or_magnitude_of_impairment – значення КВАЛІФІКАТОРІВ “Обсяг або величина порушень“;

• eHealth/ICF/qualifiers/nature_of_change_in_body_structure– значення КВАЛІФІКАТОРІВ “Природа змін у структурах організму“;

• eHealth/ICF/qualifiers/anatomical_localization– значення КВАЛІФІКАТОРІВ “Анатомічна локалізація“;

• eHealth/ICF/qualifiers/performance – значення КВАЛІФІКАТОРІВ “Виконання“;

• eHealth/ICF/qualifiers/capacity – значення КВАЛІФІКАТОРІВ “Здатність“;

• eHealth/ICF/qualifiers/barrier_or_facilitator – значення КВАЛІФІКАТОРІВ “Величина та вид впливу“;

• eHealth/ICF/observation_categories -  перелік КОМПОНЕНТ МКФ
  
  

2. Додається новий класифікатор ДЗР (ISO 9999:2016), що реалізується у вигляді довідника:

• eHealth/assistive_products – перелік допоміжних засобів реабілітації;

3. Додаються нові значення у довідник eHealth/care_plan_categories , що відображають етапи Індівідуального Реабілітаційного Плана:

• class_23 : "РЕАБІЛІТАЦІЯ У ГОСТРОМУ ПЕРІОДІ";

• class_24 : "РЕАБІЛІТАЦІЯ У ПІСЛЯГОСТРОМУ ПЕРІОДІ";

• class_25 : "РЕАБІЛІТАЦІЯ У ДОВГОТРИВАЛОМУ ПЕРІОДІ";

4. Додається новий метод Get dictionaries v2 для відображення довідників, які містять не лише код і опис значення, але й статус значення. Крім того, цей метод призначений для використання  ієрархічних словників з підпорядкованими (дочірніми) значеннями. 

Запит:

GET https://api-preprod.ehealth.gov.ua/api/v2/dictionaries?name=eHealth%2FICF%2Fclassifiers&is_active=true&value_code=b1142&value_description=Орієнтація в особі&value_is_active=true

Параметри:

Responce:

200

HEADERS

• Content-Type:application/json
  
  

Приклад довідників

2. Episode of care

1. Тип епізоду реабілітаційної допомоги фіксується у атрибуті Type == REHAB: "Реабілітація" (існуюче значення з довідника eHealth/episode_types) ;

3. Encounter 

1. Додано новий атрибут period для послідовной заміни раніше використованого атрибута date з метою розширення моделі даних відповідно до FHIR v 4.3.0 із вимогою по обов’язковому заповненню period.start та period.end під час внесення даних сутності Encounter у складі ЕМЗ реабілітаційного цикла.  Для    існуючих у ЕСОЗ    записів    про    взаємодію    проводиться   міграція   даних з встановленням значень period.start == date та period.end == date;
   Увага ! Використання атрибута encounter.period відстрочено до введення в дію та до того часу заборонено до використання у інтерфейсі МІС-ів !

2. Атрибут date тимчасово залишається у складі для забезпечення зворотньої сумісності, але в майбутньому буде виключений зі складу атрибутів Encounter;

3. Поточна модель статусів сутності Encounter залишається без змін (finished | entered-in-error).

4. Observation 

1. Сутність Observation використовується у складі Encounter data package первісного, проміжного та заключного обстеження пацієнта для фіксації значень категорійного профіля стану пацієнта відповідно до стандартів класифікації МКФ (НК 030:2022 Класифікатор функціонування, обмеження життєдіяльності та здоров'я);

2. Для фіксації кожного значення кода МКФ у складі Encounter data package створюється окремий екземпляр сутності Observation для можливості адресного посилання під час планування майбутніх реабілітаційних процедур з відповідних сутностей Activity та Service Request.

3. Визначений реабілітаційний стан формується парою значень “Категорія з довідника НК 030-2022” (що фіксується у атрибуті code, значення з довідника eHealth/ICF/classifiers), та “Кваліфікатор стану з довідника НК 030-2022” (що фіксується у атрибуті component, значеннями з довідника eHealth/ICF/qualifiers);

4. Додаткова інформація щодо проведеного обстеження, яка може бути потрібна для формування опису стану пацієнта та рекомендацій по плануванню його реабілітаційного цикла, розміщується у атрибуті comment кожного екземпляра сутності Observation.

Приклад запиту

5. Care_plan

1. Для спрощення механізма отримання доступа до ЕМЗ реабілітаційного цикла сутності Care Plan та Activity додано до переліку сутностей, на які розповсюджується правило доступа “ABAC Rule: @rule_2” - “Співробітник може читати сутність, створену в MSP працівника”;  

2. При створенні Care Plan під час реабілітації у стаціонарі (з "terms_of_service" = "inpatient") прибрано необхідність отримувати підтвердження від пацієнта на таке створення;

3. Лікар ФРМ може зробити посилання на попередній CarePlan лише у випадку, якщо попередній  CarePlan має один із статусів: COMPLETED, ACTIVE, TERMINATED;

4. Текстова інформація щодо планування поточного реабілітаційного цикла, яка може бути потрібна для формування опису стану пацієнта та рекомендацій по плануванню його реабілітаційного цикла, розміщується у атрибуті note сутності Care Plan. 

5. Інформація по необхідності використання допоміжних засобів реабілітації в межах реабілітаційного цикла додається у якості текстового опису. В описі використовуються значення з нового довідника ISO 9999:2016 без можливості деталізації номенклатури допоміжних засобів. В разі відсутності потреби у ДЗР, вони не зазначаються у CarePlan.note. Якщо потреба в фіксації такої інформації виникає під час планування активностей плана лікування, то можливо внесення текстового опису безпосередньо у атрибут activity.description ;

6. Зазначення фактично використаних допоміжних засобів при наданні реабілітаційних послуг виконується в рамках формування звітного Encounter data package у атрибуті Procedure.usedCode, який дозволяє використання масиву значень. В разі відсутності факту використання ДЗР, користувач не формує масив Procedure.usedCode;

7. До складу атрибутів додано обов’язковий атрибут managing_organization для фіксації MSP, який відповідальний за ведення реабілітаційного цикла.

6. Care_plan_activity

1. Для спрощення механізма отримання доступа до ЕМЗ реабілітаційного цикла сутності Care Plan та Activity додано до переліку сутностей, на які розповсюджується правило доступа “ABAC Rule: @rule_2” - “Співробітник може читати сутність, створену в MSP працівника”; 

2. Реєстрація усіх реабілітаційних послуг виконується у хвилинах— одиницях виміру часу наданої послуги. Це стосується атрибутів quantity, daily_amount та remaining_quantity. Валідація по відповідності одиниці виміру відпрацьовується по правилам:If $.detail.kind=service_request:

   1. Check that $.detail.quantity.system field’s value is SERVICE_UNIT.

      • Return 422 ('value is not allowed in enum')

   2. 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>')

3. Запити  на створення активності обов’язково пов’язуються з відповідними Observations у первісному, так і у проміжному/заключному обстеженні реабілітаційного цикла, при чому активність наступного цикла може пов’язуватися з обстеженнями попереднього цикла поточного епізода ІРП.  У запиті на створення активності користувач передає посилання на масив observation (з code.system =ICF) в параметрі  activity.reason_reference, у ньому зазначаються ті посилання на реабілітаційні стани МКФ, по яких планується надання реабілітаційних послуг за створюваною активністю;

4. Встановлено алгоритм фіксації значення activity.remaining_quantity для можливості автоматичного розрахунку залишкової кількості (об’єму) реабілітаційних послуг із наступними вимогами:

   1. при створенні активності activity.remaining_quantity = activity.quantity; 

   2. при створенні в Системі ServiceRequest, у якого фіксується атрибут based_on посилання на поточну активність, Система автоматично зменшує activity.remaining_quantity на кількість, що вказана у параметрі ServiceRequest.quantity.value;

5. Запланувати активність може лише employee з того  MSP, у якому створено поточний Care Plan реабілітаційного циклу (контроль відбувається по атрибуту care_plan.managing_organization);

7. Service Request

1. Створення Service Request в стаціонарі відбувається без зазначення медичної програми;

2. Зміни в Service Request Status Model:
   використання статусу In_QUEUE в моделі Program Processing statuses стає не обов’язковим. З часом цей статус буде видалено, замінено на IN_PROGRESS.
   
   

   Open

   

3. До Service Request data model додається новий атрибут quantity, Тип — Simple.quantity, у якому вказується кількість реабілітаційних процедур, що повинна бути надана за направленням. Для послуг реабілітації service_request.quantity  повинен  мати  одиницю  виміру  “хвилини” (див. вимоги до атрибуту activity.quantity).

4. До Service Request data model додається новий атрибут remaining_quantity, Тип — Simple.quantity, В якому автоматично розраховується поточний залишок кількість реабілітаційних процедур, що повинна бути надана за направленням. Для послуг реабілітації service_request.remaining_quantity  має  одиницю  виміру  “хвилини”.

5. До Service Request data model додаються нові атрибути used_by_legal_entity_history та used_by_employee_history, що заповнюються на боці ЕСОЗ автоматично. 

8. Procedure

1. До Procedure data model додається новий атрибут performed_period, Тип — Period, у якому вказується дата-час початку та кінця періоду надання реабілітаційної процедури (по яких автоматично фіксується звітний обсяг проведеної процедури у хвилинах), що повинна бути надана за направленням. По наданим даним коригується значення відповідного service_request.remaining_quantity;

2. До Procedure data model додається новий атрибут used_code, Тип — масив кодів, у якому вказується масив кодів допоміжних засобів реабілітації з довідника ДЗР (eHealth/assistive_products), які були використані під час надання реабілітаційної процедури.

Приклад запиту