...
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, який відповідальний за ведення реабілітаційного цикла.
...