Page Comparison

...

1. Care Plan  в стаціонарі створюється без СМС-інформування про це пацієнта;

2. Cтворення Care Plan для амбулаторного виконання реабілітаційних процедур супроводжується стандартним процесом отримання СМС-повідомлення;

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

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

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

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

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

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

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

...

1. Для спрощення механізма отримання доступа до ЕМЗ реабілітаційного цикла сутності Care Plan та Activity додано до переліку сутностей, на які розповсюджується правило доступа “ABAK “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);

...