ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

1. Dictionaries

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

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

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

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

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

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

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

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

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

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

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

Запит:

GET https://ehealth.edenlabllc.com/api/v2/dictionaries?name=eHealth/ICF/classifiers&is_active=true&value_code=b1142&value_description=”Орієнтація в особі” &value_is_active=true

Параметри:

name 

dictionary name

Example:

eHealth/ICF/classifiers

String

is_active 

dictionary status 

Example:

true

Boolean

value_code 

code of the dictionary value 

Example:

b1142

String

value_description 

description of the dictionary value

Example:

Орієнтація в особі 

String

value_is_active 

status of the dictionary value 

Example:

true

String

Responce:

200

HEADERS

  • Content-Type:application/json

 Click here to expand...
{

  "meta": {

    "code": 200,

    "url": "https://example.com/resource",

    "type": "object",

    "request_id": "6617aeec-15e2-4d6f-b9bd-53559c358f97#17810"

  },

  "data": [

    {

      "name": "eHealth/ICF/classifiers",

      "description": "Класифікатори МКФ",

      "values": [

        {

          "code": "b1142",

          "description": "Орієнтація в особі",

          "is_active": true,

          "child_values": [

            {

              "code": "b11429",

              "description": "Орієнтація в особі неуточнена",

              "is_active": true,

              "child_values": []

            }

          ]

        }

      ],

      "labels": [

        "SYSTEM",

        "EXTERNAL"

      ],

      "is_active": true

    },

    {

      "name": "eHealth/ICPC2/condition_codes",

      "description": "Коди станів за ICPC2",

      "values": [

        {

          "code": "D88",

          "description": "Апендицит",

          "is_active": true,

          "child_values": []

        }

      ],

      "labels": [

        "SYSTEM",

        "EXTERNAL"

      ],

      "is_active": true

    }

  ]

}

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;

  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” (що фіксується у атрибуті value, значення з довідника eHealth/ICF/qualifiers);

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

5. Care_plan

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

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

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

6. Care_plan_activity

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

  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, Тип — масив кодів, у якому вказується масив кодів допоміжних засобів реабілітації з довідника ISO 9999, які були використані під час надання реабілітаційної процедури.

  • No labels

ЕСОЗ - публічна документація