| Table of Contents |
|---|
Ціль
Даний веб-сервіс дозволяє створити План лікування з активностями для одного пацієнта.
...
Тільки автотифікований та авторизований користувач (DOCTOR або SPECIALIST) з відповідною спеціальністю, вказаної в config, має можливість створення Плану лікування.
План лікування може бути створений від юридичної особи MSP, PRIMARY_CARE або OUTPATIENT.
План лікування повинен бути підписаний за допомогою електронного ключа.
Плін лікування створюється в асинхронний спосіб, як і всі медичні події.
Активності до Плану лікування додаються за допомогою сервісу Create Care Plan activities. Але, План лікування може бути відокремлено створено без активностей.
...
Отримати patient_id з URL
Первірити статус пацієнта/неідентифікованої особи активний
в разі помилки - повернути код 409 ('Person is not active')
Перевірити, що verification_status персони не дорівнює NOT_VERIFIED.
в разі помилки повернути 409, "Patient is not verified"
Захешувати patient_id та зберегти в поле $.subject
...
Отримати 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”)
...
Первірити, що посилання валідне на ресурс взаємодії
Перевірити, що взаємодія активна (статус НЕ 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')
...
Перевірити, що воно має значення =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 як
Сформувати заявку
Сгенерувати номер заявки (див Human readable requisition number), який має посилання на id Плану лікування
Встановити атрибути $.requisition
...
Якщо пацієнт - не неідентифікована особа та його метод автентифікації визначений Determination of a default authentication method and return person's active auth_methods як OTP або third_person.OTP, відправити СМС до пацієнта з номером заявки.
Якщо поле inform_with вказано то відправити SMS пацієнту з номером заявки у відповідності до вказаного каналу комунікації.