API. Create Care Plan_UA

Ціль

Даний веб-сервіс дозволяє створити План лікування з активностями для одного пацієнта.

Основні положення

1. Тільки автотифікований та авторизований користувач (DOCTOR або SPECIALIST) з відповідною спеціальністю, вказаної в config, має можливість створення Плану лікування.

2. План лікування може бути створений від юридичної особи MSP, PRIMARY_CARE або OUTPATIENT.

3. План лікування повинен бути підписаний за допомогою електронного ключа.

4. Плін лікування створюється в асинхронний спосіб, як і всі медичні події.

5. Активності до Плану лікування додаються за допомогою сервісу Create Care Plan activities. Але, План лікування може бути відокремлено створено без активностей.

Специфікація

Apiary

Авторизація

• Перевірити валідність токену доступу

  • в разі помилки валідації - повернути код 401 (“Invalid access token”)

• Перевірити строк дії токену доступу

  • в разі помилки - повернути код 401 (“Invalid access token”)

• Перевірити скопи користувачів на наявність запрошеної операції (scope = 'care_plan:write')

  • в разі відсутності запрошеного скоупу повернути код помилки 403 (“Your scope does not allow to access this resource. Missing allowances: care_plan:write”)

Перевірити запит

Перевірити закодований та декодований запит, використовуючи схему. Повернути 422 з переліком помилок перевірок, якщо є невідповідність схемам.

Первірити електронний підпис

• Перевірити, що на запит закладено підпис

  • в разі помилки - повернути код 422 (“document must be signed by 1 signer but contains 0 signatures”)

• Перевірити валідність цифрового підпису, та строк його дії

• Перевірити, що цифровий підпис належить автору Плану лікування ($.author)

  • Первірити, що DRFO електронного підпису та party.tax_id автору співпадають

    • в разі помилки - повернути код 409 (“Signer DRFO doesn't match with requester tax_id“)

Перевірити юридичну особу

• Отриманий client_id з токену.

  • в разі помилки - повернути код 403 (“Your scope does not allow to access this resource. Missing allowances: care_plan:write”)

• Перевірити статус юридичної особи (status = ACTIVE)

  • в разі помилки - повернути код 409 ('client_id refers to legal entity that is not active')

• Перевірити, що тип юридичної особи відповідє конфігураційному параметру ME_ALLOWED_TRANSACTIONS_LE_TYPES

  • в разі помилки - повернути код 409 ('client_id refers to legal entity with type that is not allowed to create medical events transactions')

Перевірити План лікування

Перевірити наступні параметри Плану лікування:

1. Суб'єкт

Перевірити, що дані пов'язані з person_id з URL, відповідають.

• Отримати patient_id з URL

• Первірити статус пацієнта/неідентифікованої особи активний

  • в разі помилки - повернути код 409 ('Person is not active')

• Перевірити, що verification_status персони не дорівнює NOT_VERIFIED.

  • в разі помилки повернути 409, "Patient is not verified"

• Захешувати patient_id та зберегти в поле $.subject

2. Автор

Первірити наявність заповненого значення в полі $.author.

• Отримати user_id з токену. Первірити, що автор належить до користувачів, які є співробітниками.

  • в разі помилки - повернути код 422 ('User is not allowed to create care plan for the employee')

• Первірити, що автор активний та погоджений та належить до юридичної особи (client_id from token).

  • в разі помилки - повернути код 403 ('Access denied')

• Первірити тип співробітника:

  • якщо SPECIALIST:

    • Перевірити, що співробітник має хоча б одну роль, яка:

      • активна та має активний статус

      • відповідає сервісу healthcare зі значенням providing_conditions=$.terms_of_service

        • в разі помилки - повернути код 422 ('Employee does not have active role that correspond to the submitted terms of service')

  • Для DOCTOR, додаткові перевірки не потрібні

• Перевірити спеціалізацію автора (speciality_officio == true) вказану в config для вказаної категорії плану лікування.

  • в разі помилки - повернути код 409 (“Invalid employee speciality”)

3. Категорія

Перевірити наявність заповненого значення в полі $.category.

• Перевірити, що значення допустиме згідно довідника eHealth/care_plan_categories (diabetics, по-замовчуванню).

  • в разі помилки - повернути код 422 ('value is not allowed in enum')

4. Взаємодії

Перевірити начвність заповненого значення в полі $.encounter.

• Первірити, що посилання валідне на ресурс взаємодії

  • Перевірити, що взаємодія активна (статус НЕ entered_in_error)

    • в разі помилки - повернути код 422 ('Encounter in "entered_in_error" status can not be referenced')

  • Первірити, що взаємодія пов'язана з пацієнтом ($.subject)

    • в разі помилки - повернути код 422 ('Encounter with such id is not found')

• Первірити первинні діагнози у взаємодії:

  • Перевірити, що код стану є в переліку доступних кодів станів для категоріїї Плану лікування diabetics (значення чартів: в config)

    • в разі помилки - повернути код 422 ('Primary diagnosis condition code and care plan category mismatch')

  • Первірити, що system/codes повністю відповідають значенню в полі Addresses

    • в разі помилки - повернути код 422 ('Primary diagnosis condition codes do not match with codes in addresses'), для випадку, коли код станів в addresses не таке як діагнозі взаємодії.

• Перевірити, що епізод пов'язаний зі взаємодією:

  • існує

    • в разі помилки - повернути код 422 ('Encounter refers to episode that does not exist')

  • активний

    • в разі помилки - повернути код 422 ('Encounter refers to episode that is not active')

  • керуюча компанія відповідє юридичній особі автора (client_id)

    • в разі помилки - повернути код 422 ('Encounter is from another legal entity')

5. Адреси

Первірити заповненість поля $.addresses.

• Первірити наявність масиву на наявність в ньому даних з відповідним типом кодування

  • в разі помилки - повернути код 422 про невідповідність типу або помилку некоректної перевірки схеми

• Перевірити, що система є значенням з довідника eHealth/ICD10_AM/condition_codes або eHealth/ICPC2/condition_codes(повинні відповідати первинні діагнози систем/кодів у взаємодії)

  • в разі помилки - повернути код 422 ('value is not allowed in enum')

6. Умови надання послуг

Перевірити заповненність значення в полі $.terms_of_service

• Первірити, що значення з довідника PROVIDING_CONDITION.

  • в разі помилки - повернути код 422 ('value is not allowed in enum')

• Перевірити отримані дані:

  • Якщо спеціальність автора - DOCTOR, то значення FIELD та OUTPATIENT допустимі

  • Якщо спеціальність автора - SPECIALIST, то значення INPATIENT та OUTPATIENT допустимі

    • в разі помилки - повернути код 422 ('Not allowed for <employee type>')

7. Період

Первірити заповненність значення в полі $.period.

• Перевірити, що $.period.start >=encounter.date.

  • в разі помилки - повернути код 422 ('Start date must be in the future')

• Перевірити, що $.period.end >= $.period.start

  • в разі помилки - повернути код 422 ('End date must be greater than or equal the start date')

8. Створено на основі

Первірити заповненість значення в полі $.based_on.

• Перевірити, що План лікування, на яке є посилання - валідний

• Перевірити План лікування, на який є посилання:

  • Перевірити, що він відноситься до того ж пацієнта ($.subject)

    • Повернути 422 ('Care plan with such id is not found')

9. Приналежність

Перевірити заповненість значення в полі $.part_of

• Перевірити, що План лікування, на яке є посилання - валідний

• Перевірити План лікування, на який є посилання:

  • Перевірити, що він відноситься до того ж пацієнта ($.subject)

    • Повернути 422 ('Care plan with such id is not found')

10. Супроводжуюча інформація

Перевірити заповненість значення в полі $.supporting_info

• Первірити, що значення є в масиві типів episode_of_care, procedure або diagnostic report

  • в разі помилки - повернути код 422 ('value is not allowed in enum')

• Первірити, що кожне посилання є:

  • валідною медичною подією з визначеним типом вище

  • належить пацієнту ($.subject)

    • в разі помилки - повернути код 422 ('<medical event type> with such ID is not found')

11. Врач на заміну

Перевірити заповненість значення в полі $.contributor

• Перевірити, що значення є в масиві типів співробітників

  • в разі помилки - повернути код 422 ('value is not allowed in enum')

• Перевірити, що кожен співробітник, на якого є посилання - активний та погоджений

  • в разі помилки - повернути код 422 ('Invalid employee status')

12. Ідентифікатор Плану лікування

Первірити, що поле заповнене $.id

• Перевірити, о воно унікальне та в форматі UUID

  • в разі помилки - повернути код 409 ("Care plan with such id already exists")

13. Статус

Перевірити, що поле заповнене $.status

• Перевірити, що воно має значення =new

  • в разі помилки - повернути код 422 ('value is not allowed in enum')

14. Inform_with

Користувач може передати id методу автентифікації персони, за допомогою якого від має намір отримати номер заявки на створення плану лікування. Необхідний метож автентифікації може бути знайдений по Get person's auth methods

Дане поле опціональне та встановлюється в новому полі inform_with та зберігає тип та phone_number в care_plans.urgent.informing_method_current. Номер телефону має бути захешований перед збереженням medical_data.care_plans.urgent.informing_method_current.phone_number

Перевірити значення в полі $.inform_with, якщо вказано:

• якщо $.auth_method_id вказано

  • Перевірити метод автентифікації:

    • якщо вказано в MPI.person_authentication_method

    • належить пацієнту (MPI.person_authentication_method.person_id = $.patient_id)

    • активний (MPI.person_authentication_method.ended_at > now() та MPI.person_authentication_method.is_active = true)

  • в разі неуспішності будь-якої з даних перевірок згенерувати помилку: 422, "Authentication method doesn't exist, is inactive or does not belong to this person"

• Якщо створений план лікування не має даного поля, то вибрати метод, що повертається з mpi як 

  Determination of a default authentication method and return person's active auth_methods

Сформувати заявку

• Сгенерувати номер заявки (див Human readable requisition number), який має посилання на id Плану лікування

• Встановити атрибути $.requisition

Примітка: номер заявки повинен бути унікальним для кожного Плану лікування і не повинен співпадати з номером інших сутностей.

Логіка сервісу

1. Зберегти підписаний контент до файлового сховища

2. Зберегти дату до колекції care_plans в БД у відповідності до Care plan data model

3. Зберегти посилання з файлового сховища до поля $.signed_content_links в колекції плану лікування

4. Створитии задачу та повернути її id.

Відправити СМС-повідомлення

Якщо пацієнт - не неідентифікована особа та його метод автентифікації визначений  Determination of a default authentication method and return person's active auth_methods як OTP або third_person.OTP, відправити СМС до пацієнта з номером заявки.

Якщо поле inform_with вказано то відправити SMS пацієнту з номером заявки у відповідності до вказаного каналу комунікації.