Мета

Цей WS призначений для реєстрації пацієнта в системі на основі даних, отриманих з інформаційної системи пацієнтів

Ключові положення

1. Даний метод має використовуватися тільки фронт-енд частиною Auth

2. Перевірити токен сессії (jwt), що було отримано як результат підписаного контенту як результат перевірки даних пацієнтів по PIS. Confidant patient sign-up validation та підписаного контенту, пропустити повторну перевірку даних пацієнта.

3. Створюється користувач і пацієнт в системі

4. Генерується токен доступу для подальних дій

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

Apiary

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

Авторизація

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

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

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

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

• Перевірити скоупи користувача на можливість виконання даної дії (scope = confidant_person:sign_up)

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

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

• Перевірити, що signed_content та signed_content_encoding вказані

  • в разі помилки - повернути 422 ('required property signed_content was not present' or ‘required property signed_content_encoding was not present')

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

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

• Перевірити, що підписаний контент закодовано в значенні 'base64'

  • в разі помилки - повернути 422 ('is invalid')

• Перевірити, що цифровий підпис валідний

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

• Перевірити, що підписант запиту відповідає автентифікованій персоні. Отримати персону з MPI використовуючи x-person-id та впевневшись, що person.tax_id або person.documents рівний drfo підписанта (з цифрового підпису)

  • якщо значення drfo рівне tax_id з врахуванням regexp (^[0-9]{10}$) - порівняти з person.tax_id

  • якщо drfo рівне номеру national_id з врахуванням regexp (^[0-9]{9}$) - порівняти з документом типу 'NATIONAL_ID'

  • якщо значення drfo містить хоча б одну літеру, виконати зворотну транслітерацію поля використовуючи існуючий алгоритм (описаний тут), тоді перевірити, що значення рівне номеру паспорту з врахуванням regexp (^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$) - порівняти зі значенням документу типу 'PASSPORT'

    • в разі помилки - повернути 401 ('Unable to authenticate signer')

Перевірити JWT

Впевнетись, що токен наданий в пейлоад (отриманий з PIS. Confidant patient sign-up validation ) є валідним:

• перевірити підпис JWT

• перевірити емітента (iss = Ehealth)

• перевірити aud (aud = pis-registration)

• перевірити дату закінчення строку дії (exp у майбутньому)

• перевірити, що content_hash рівний значенню хеш MD5 в полі signed_content

  • в разі будь-якої помилки - повернути 401 ('Unauthorized')

Перевірити запит на реєстрацію персони

• Перевірити дані персони у відповідності до Rules to validate patient data | Person with confidant

• Перевірити, що confidant_person.person_id це та ж людина, що і підписант запиту (confidant_person.person_id = x-person-id)

  • в разі помилки - повернути 422 ('Confidant person and signer must be the same')

• Перевірити значення поля patient_signed, що рівне ‘true’

  • в разі помилки - повернути 422 ('expected true but got false for attribute %{attribute}')

• Перевірити значення поля process_disclosure_data_consent, що рівне ‘true’

  • в разі помилки - повернути 422 ('expected true but got false for attribute %{attribute}')

Сервісна логіка

Знайти персону

1. Здійснити пошук активної персони в базі даних mpi з даними по персоні з запиту на реєстрацію у відповідності до існуючого процесу, описаного тут Create/Update person request | Search person
   Розразувати скор згідно результатів порівнянн між знайденою активною персоною та персоною з запиту на реєстрацію, використовуючи процес дедублікації, описаний тут UA_Deduplication process NEW
   Порівняти отриманий скор зі значенням конфігураційного параметру PIS_ONLINE_DEDUPLICATION_MATCH_SCORE, встановити 0.95’:

   1. якщо знайдено одну активну персону з порівняльним скором > PIS_ONLINE_DEDUPLICATION_MATCH_SCORE - зберегти її person_id та перейти на крок PIS. Confidant patient sign-up registration | Check confidant person relationship

   2. якщо знайдено більше одної персони з порівняльним скором > PIS_ONLINE_DEDUPLICATION_MATCH_SCORE - повернути 401 ('It is impossible to uniquely identify the person.')

   3. якщо відсутністі активні персони з порівняльним скором > PIS_ONLINE_DEDUPLICATION_MATCH_SCORE - перейти до PIS. Confidant patient sign-up registration | Create person

Створити персону

1. Створити нову персону в базу даних mpi, встановит значення в наступних таблицях на основі персони з запиту на реєстрацію:

   1. persons таблиця

   2. person_phones таблиця

   3. person_addresses таблиця

   4. person_documents таблиця

   5. person_authentication_methods таблиця

2. Зберегти підписаний контент до медіа-сховища

3. Відправити персону на перевірку - створити запит в таблиці person_verifications для person_id, встановити значення для кожного стріма з верифікації:

   1. Ручна верифікація NHS

      1. якщо $.person.confidant_person присутній в запиті на реєстрацію персони або $.person.documents містить документ з типом = 'PERMANENT_RESIDENCE_PERMIT' або  $.person.unzr не пустий та перші 8 цифр $.person.unzr != $.person.birth_date

         1. встановити nhs_verification_status = NOT_VERIFIED

         2. встановити nhs_verification_reason = DOCUMENTS_TRIGGERED

      2. в іншому випадку - скан-копії документів особи не потрібні, встановити статус верифікації у відповідності до логіки, описаної тут: Sign person request | Manual NHS verification

   2. верифікація з реєстром DRFO - у відповідності до логіки, описаної тут:Sign person request | DRFO registry verification

   3. верифікація з реєстром актів смерті DRACS -у відповідності до логіки, описаної тут: Sign person request | DRACS death acts registry verification

4. Розрахувати кумулятивний статус верифікації у відповідності до логіки, описаної тут: Sign person request | Calculate cumulative verification status

Створити взаємозв'язок з довіреною особою

Служба має створити неперевірені відносини між довіреною особою та пов’язаною особою для подальшої перевірки відповідальною особою зі сторони НСЗУ:

• Викликати UA_Create confidant person relationship . Встановити значення:

  • confidant_person_id = $request.confidant_person.person_id

  • person_id = person.id

  • verification_status = “VERIFICATION_NEEDED”

  • verification_reason = “ONLINE_TRIGGERED_BY_PIS_REGISTRATION_VIA_CONFIDANT“

  • confidant_person_relationship_documents = person.confidant_person.documents_relationship

  В разі, якщо вік персони < person_full_legal_capacity_age років:

  • розрахувати relationship_expiration_date - дата, коли персона стає person_full_legal_capacity_age

  • перевірити if $.active_to <= relationship_expiration_date

    • якщо true - встановити active_to = $.active_to

    • в іншому випадку - встановити active_to = relationship_expiration_date

Перевірити взаємозв'язок з довіреною особою

Отримати confidant_person_id з токену (новий хедер x-person-id)

Перевірити взаємозв'язок використовуючи UA_Check confidant person relationship та маючи confidant_person_id та person_id

1. якщо взаємозв'язок не існує - створити взаємозв'язок PIS. Confidant patient sign-up registration | Create confidant person relationship

Знайти користувача в Mithril

1. Здійснити пошук існуючого користувача в базі даних mithril, таблиця users, з person_id = person_id та is_active = true

   1. якщо користувача знайдено - перевірити, що він не заблокований (is_blocked <> true)

      1. в разі, якщо заблокований - повернути 401 ('User is blocked.').

      2. якщо не заблокований - зберегти його user_id та перейти до кроку p.3.

   2. якщо користувача не знайдено - перейти до кроку p.4.

Створити користувача, якщо не існує

1. Створити користувача для активної персони в базі даних mithril, таблиця users, встановити:

   1. id = автогенерований uuid

   2. settings = ‘{“trusted_source”: false}’

   3. priv_settings = ‘{"login_hstr": [], "otp_error_counter": 0}’

   4. inserted_at = now()

   5. updated_at = now()

   6. password_set_at = now()

   7. tax_id = tax_id або document.number з пейлоад (якщо передано обидва - то використовувати tax_id)

   8. person_id = person_id персони, що було знайдено на кроці пошуку персони

2. Створити глобальну роль для створеного користувача в базі даних mithril, таблиця global_user_roles , встановити:

   1. id = автогенерований uuid

   2. user_id = user_id користувача створеного на кроці p.4

   3. role_id = id ролі з назвою ‘PATIENT’

   4. inserted_at = now()

   5. updated_at = now()

Згенерувати авторизаційний токен

1. Згенерувати auth_token зі скоупом app:authorize для user_id та client_id of Auth UI (from env)

2. Зберегти токен до бази даних mithil, таблиця tokens, встановити:

   1. id = uuid токену

   2. name = назва токену (‘access_token’)

   3. value = захешований токен

   4. expires_at = дата та час строку дії токену у форматі unix-time

   5. details = додаткові деталі токену (scopes, client_id, grant_type)

   6. user_id = id користувача

   7. inserted_at = now()

   8. updated_at = now()

3. Відобразити відповідь у відповідності до специфікації.