Ціль

1. Даний веб-сервіс (WS) розроблено для створення дозволу на сутність, що є агрегуючою сутністю (контекстом) для інших сутностей (episode_of_care, diagnostic_report, care_plan), АБО заборонену групу АБО дігностичний звіт, АБО на service_request з врахуванням його permitted_resources АБО на відміну взаємодії чи процедури.

2. Дозволи обробляються асинхронним шляхом.

3. Тільки автентифіковані та авторизовані співробітники з відповідним скоупом можуть створювати доступи.

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

1. API Create Approval

...

Перевірити запит на основі схеми JSON

Авторизація

...

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

...

Перевірити скоупи користувачів approval:create на можливість виконання даної операції

Логіка

...

Апрували виконуються в асинхронний спосіб

...

Користувач може сворити апрувал тільки для співробітника його юридичної особи

1. client_id з токену повинен бути поєднаним з employee_id від об'єкту granted_to.

2. granted_to.employee_id повинен бути активним.
   

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

2. Перевірити, що токен дійсний

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

3. Перевірити скоупи користувача на можливість виконання даної дії (scope = 'approval:create ')

   1. повернути 403 (“Your scope does not allow to access this resource. Missing allowances: approval:create ”) в разі невалідних скоупів

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

Перевірити користувача

1. Granted_to.employee_id повинні бути активні

   1. в разі помилки - повернути 422 “Should be active“

2. Перевірити, що співробітник належіть тій самій юридичній особі що і користувач:

   1. client_id з токену повинен бути пов'язаний з employee_id з об'єкту granted_to.

      1. в разі помилки - повернути 422 “Employee <employee_id> doesn't belong to your legal entity“

Перевірити ресурси чи блоки ресурсів

1. Дозволи відпрацьовуються асинхронно

Перевірити ресурси

1. якщо episode_of_care вказано в запиті як код ресурсу

   1. Перевірити, що episode_of_care в рапиті існує та знаходиться в статусі активний або закритий в DB

      1. в разі помилки - повернути 422 (Episode is canceled)

2. якщо diagnostic_report вказано в запиті як код ресурсу

   1. Перевірити, що блок diagnostic_report в запиті існує в фінальному статусі в DB

      1. в разі помилки - повернути 422 (Diagnostic report in \"entered_in_error\" status can not be referenced or Diagnostic report with such id is not found)

3. якщо care_plan вказано в запиті як код ресурсу

   1. Перевірити care_plan з запиту присутній в DB

      1. в разі помилки - повернути 422 (Care plan with such id is not found)

   2. Перевірити, що в запиті відсутні інші об'єкти

      1. в разі помилки - повернути 422 (Approval for care plan can not contain other entities)

4. якщо взаємодія наявна вказана в запиті як код ресурсу

   1. Перевірити, що взаємодія з запиту присутня в DB

      1. в разі помилки - повернути 422 (not found)

5. якщо процедура присутня в запиті як блок ресурсу

   1. Перевірити, що процедура з запиту присутня в DB

      1. в разі помилки - повернути 422 (not found)

Перевірити service_request

1. Якщо блок service_request присутній в запиті

   1. Get Service_request details

...

1. 1.  (тільки в

...

1. 1. активному стані)

...

1. 1. використати Response.permitted_resources як

...

1. 1. ресурс для

...

1. 1. доступу  (

...

1. 1. можуть бути епізод

...

1. 1. чи diagnostic_report).

...

Перевірити forbidden_group

1. Якщо блок forbidden_

...

1. group вказано в запиті

   1. Check forbidden group in the request exists and is_active in DB

      1. in case of error return - 404 (not found)

Перевірити diagnoses_group

1. Якщо diagnoses_group block вказано в запиті

   1. Check diagnoses_group in the request exists and is_active in DB

      1. in case of error return - 404 (not found)

Перевірити пацієнта

1. Якщо patient block вказано в запиті

   1. Отримати patient_id з URL:

      1. Перевірити, що person_id з запиту відповідає patient_id з URL

         1. в разі помилки - повернути 404 (“Approval for one patient can not be created in another patient’s context”)

      2. існує та is_active в

...

1. 1. 1. DB

         1. в разі помилки - повернути

...

1. 1. 1. 1. 404 (Person is not found

...

1. 1. 1. 1. )

Перевірити блок child_resource

1. Якщо child_resource не пустий:

   1. перевірити, що access_level == read

      1. в разі помилки - повернути 422 ("$.access_level. value is not allowed in enum")

   2. перевірити, що контекст $.child_resource.identifier.value відповідає $.resource.identifier.value

      1. в разі помилки - повернути 422 (Child resource context id is not equal to granted resource id)

   3. перевірити, що service_requests / forbidden_groups / diagnoses_group / patients не заповнені

      1. в разі помилки - повернути 422 (schema does not allow additional properties)

   4. перевірити, що максимальна кількість сутностей в ресурсі = 1

      1. в разі помилки - повернути 422 ($.resources.expected a maximum of 1 items but got 2)

Перевірити authentication_method персони

1. Перевірити patient_id:

...

1. 1. якщо

...

1. 1. належить person,

...

1. 1. то GET auth_method

...

1. 1. використовує MPI

...

1. 1. {patient_id}

      1. якщо це OTP:

...

1. 1. 1. 1. направити SMS

...

1. 1. 1. 1. на auth_phone

...

1. 1. 1. 1. по otpч_verification

...

1. 1. 1. 1. сервіс POST /verifications

         2. зберегти

...

1. 1. 1. 1. погодження до DB

         2. зберегти authentication_method_current.type та номер

...

1. 1. 1. 1. до DB

...

1. 1. 1. 1. повернути authentication_method_current.type = OTP

      2. якщо

...

1. 1. 1. оф-лайн

         1. зберегти

...

1. 1. 1. 1. доступ до DB

         2. зберегти authentication_method_current.type

...

1. 1. 1. 1. and number to DB

         2. повернути  authentication_method_current.type = offline

...

1. 1. 1.  якщо це null:

         1. повернути

...

1. 1. 1. 1. error 409 (Person

...

1. 1. 1. 1. does not have active authentication

...

1. 1. 1. 1. method)

   2. якщо належить

...

1. 1. preperson:

      1. зберегти

...

1. 1. 1. погодження до

...

1. 1. 1. DB

      2. встановити

...

1. 1. 1. для доступу status

...

1. 1. 1. = active

      2. встановити

...

1. 1. 1. для доступу urgent = null 

Перевірити access_level

1. Перевірити, що access_level відповідає granted_resources:

   1. в разі помилки повернути

...

1. 1. 422 ("Resource types [\"$.granted_resources[].code\"] not allowed to use write access_level")

Перевірити authorize_with

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

1. перевірити

...

1. auth_method.

...

1. id в UUID

   1. в разі помилки

...

1. 1. повернути 422

2. знайти

...

1. метод автентифікації в MPI.person_authentication_method

   1. в разі помилки

...

1. 1. повернути 422, "such authentication method doesn't exist"

2. знайти

...

1. метод автентифікації пацієнта,

...

1. де MPI.person_authentication_method.person_id = $.patient.id

   1. в разі помилки

...

1. 1. повернути 422, "such authentication method does not belong to this person"

2. перевірити, що auth_method.type = NA

   1. повернути помилку 422, "Сannot be confirmed by a method with type= NA. Use a different method."

3. перевірити, що

...

1. метод автентифікації активний (authentication_method.ended_at > now() та is_active = true)

Дане поле опціональне/не обов'язкове та вказане в некількох полях Поле опційне та встановити в нове поле authorize_with та зберігає  та зберегти type та  та phone_number в approvals.urgent.authentication_method_current.

Якщо апрувал дозвіл не має даних полівцього поля, тоді то вибрати той метод, який повертається з mpi як як person's default method.

Відмінити існуючий дозвіл

Знайти, якщо існують активні та дійсні дозволи, надані поточним patient_id, для тих же granted_resources, granted_to та access_level з запиту.

• Якщо знайдено - встановити їх статус на terminated. Такод, встановити updated_at та updated_by поточному користувачу.

Додаткова логіка

1. Всі

...

1. дозволи в статусі "new"

...

1. повинна бути

...

1. видалена через 12

...

1. hours після створення -

...

1. env. configuration parameter

2. Всі

...

1. дозволи з forbidden_group має свій власний expires_at

...

1. config parameter - env. configuration parameter

2. Всі дозволи з care_plan має свій власний expires_at config parameter - env. configuration parameter

3. Всі дозволи на картку пацієнта має свій власний expires_at config parameter - env. configuration parameter

4. Дозволи з child_resources буде створено на сутність, яка є контекстом для child_resources

5. Для дозволів на child_resource з ресурсом або service_request:

   1. встановити child_resource до блоку reason

   2. встановити service_request до блоку reason

6. Перевірити, чи granted_resource та\чи reason мають коди заборонених груп:

   1. якщо є записи з заборонених груп

      1. перевірити тип authentication_method для пацієнта

         1. якщо тип 'OTP' відправити SMS (Код <code> для доступу до даних про ВІЛ/РПП https://bit.ly/nszu1677f )

   2. якщо немає записів з заборонених груп та блок diagnoses_group вказано в запиті

      1. якщо група діагнозів містить коди з довідника ICD10:

         1. перевірити тип authentication_method для пацієнта

            1. якщо тип 'OTP' відправити SMS (Код <code>: доступ на групу діагнозів {diagnoses_group_code} http://bit.ly/nszu1677b )

      2. якщо група діагнозів містить коди з довідника ICPC2:

         1. перевірити тип authentication_method для пацієнта

            1. якщо тип 'OTP' відправити SMS (Код <code> доступ на групу діагнозів {diagnoses_group_code} http://bit.ly/nszu1677e )

   3. якщо відсутні коди заборонених груп

      1. перевірити тип authentication_method по пацієнту

         1. якщо тип = 'OTP' відправити SMS (Код авторизації дій в системі eHealth: <code>')