ЕСОЗ - публічна документація
PIS. Complete Update Person details_UA
- 1 Мета
- 2 Специфікація
- 3 Основні положення
- 4 Сервісна логіка
- 4.1 Зберегти підписаний запит на персону до сховища даних
- 4.2 Оновити запит на персону
- 4.3 Оновити запити на декларацію зі статусом
- 4.4 Оновити персону
- 4.5 Вказати персону для верифікації
- 4.6 Розрахувати комулятивний статус верифікації
- 4.7 Оновити взаємозв'язок між довіреною персоною та оновленою персоною
- 4.8 Відобразити відповідь
Мета
Даний веб-сервіс (WS) використовується для завершення запиту на персону для оновлення даних персони у відповідності до його id, який було знайдено перед цим, використовуючи person_id з токену доступу.
Специфікація
Основні положення
Даний веб-сервіс (WS) має використовуватись тільки для завершення запиту на персону при оновленні існуючої персони в системі.
Тільки запит на персону, створений через PIS має завершуватись даним веб-сервісом (WS).
Перед завершенням - скан-копії документів персони можуть бути завантажені до сховища даних.
Авторизація
Перевірити валідність токену доступу
Повернути (401, 'Invalid access token') в разі неуспішних перевірок
Перевірити, що токен дійсний
в разі помилки - повернути (401, 'Invalid access token')
Перевірити скоупи користувача на можливість виконання даної дії (scope = 'person_request:write_pis')
Повернути (403, 'Your scope does not allow to access this resource. Missing allowances: person_request:write_pis') в разі невалідних скоупів
Перевірити, що токен містисть person_id
в разі помилки - повернути (401, 'Invalid access token')
Перевірити персону
Отримати
person_id
з токену (x-person-id
header)Перевірити, що статус персони активний (status = ‘active' & is_active = 'true’)
в разі помилки - повернути 404 ('Person is not found')
Перевірити довірену особу та взаємозв'язок
Якщо персона юридично не дієздатна - система має переконатись, що її дані оновлюються довіреною особою та є зареєстрований та верифікований взаємозв'язок.
Отримати applicant_person_id
з токену, порівняти цого до person_id
з токену:
якщо рівний - перевірити, що персона має бути не авторизована як довірена особа, що вона не відповідає наступним правилам:
вік персони < no_self_registration_age глобальному параметру;
що вік персони між значенням no_self_registration_age та person_full_legal_capacity_age глобальних параметрів та персона не має документу з типом з конфігураційного параметру PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES;
вік персони > person_full_legal_capacity_age глобального параметру та існує хоча б один взаємозв'язок активний та погоджений з довіреною особою з персоною (викорисовуючи наступний процес Check confidant person relationship з person_id = person з запиту - очікується відповідь
:ok, :approved
)в разі помилки - повернути 409 (‘Request must be authorized by confidant person’)
Якщо не рівний - перевірити взаємозв'язок по наступним крокам:
Перевірити, що зареєстрований взаємозв'язок між
person_id
таapplicant_person_id
(MPI.confidant_person_relationships)Перевірити, що взаємозв'язок є VERIFIED
в разі помилки - повернути 409 (‘Can’t confirm relationship’)
Перевірити, що існує
applicant_person_id
(status = 'active' & is_active = 'true') та має будь-який verification_status але неNOT_VERIFIED
в разі помилки - повернути 409 (‘Confidant person not found or is not verified’)
Перевірити запит
Перевірити закодований та декодований запит у відповідності до схеми JSON
в разі, якщо значення поля не відповідає схемі - повернути 422 з повідомленням у відповідності до поля
в разі, якщо додаткові поля присутні в запиті - повернути 422 ('schema does not allow additional properties')
в разі, якщо потрібні параметри не присутні в запиті - повернути 422 ('required property %{property} was not present')
в разі, якщо необхідний набір параметрів не присутній в запиті - повернути 422 ('expected a minimum of %{min} items but got %{actual}')
Перевірити, що запит на персону з URL вказані в базі даних IL, таблиця person_requests, з person_data_id = person_id з токену
в разі помилки - повернути 404 ('Person request not found')
Перевірити статус зміни
Тільки запити на персону в статусі NEW та PIS може бути завершений.
Перевірити, що запит на персону для URL має статус = NEW та канал = PiS
в разі помилки - повернути 409 ('Invalid transition')
Перевірити підписний контент
Перевірити, що поле
$.signed_content
це валідний рядок base64в разі помилки - повернути 422 ('Not a base64 string')
Перевірити, що значення поля
$.signed_content_encoding
рівний 'base64'в разі помилки - повернути 422 ('value is not allowed in enum')
Перевірити, що поле
$.signed_content
містить цифровий підписв разі помилки - повернути 400 ('Invalid signature')
Перевірити цифровий підпис для
$.signed_content
валіднийв разі помилки - повернути 400 з помилкою валідації цифрового підпису
Перевірити, що декодований підписний контент відповідає з попереднього збереженим в таблиці
person_requests
для запиту на персону (окрім поля$.patient_signed
)в разі помилки - повернути 422 ('Signed content does not match the previously created content')
Перевірити, що поле
drfo
в цифровому підписі рівний персоні, що завершує запит, на основі поляapplicant_person_id
з токенуякщо
applicant_person_id
= person_id з токену - порівняти з персоною з запитуякщо значення рівне tax_id regexp (
^[0-9]{10}$
), полу містить tax_id, використати полеtax_id
з запиту на персону для порівняння;якщо значення рівне номеру national_id regexp (
^[0-9]{9}$
), поле містить номер national_id, використовувати полеdocuments.number
зdocuments.type = 'NATIONAL_ID'
для порівняння;якщо значення містить хоча б одну літеру, виконати зворотню транслітерацію поля, використовуючи існуючий алгоритм (описаний тут), тоді перевірити, що значення рівне номеру паспорту regexp (
^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$
), в разі рівності, поле містить номер паспорту, використати полеdocuments.number
зdocuments.type = 'PASSPORT'
для порівняння;
якщо
applicant_person_id
!= person_id з токену - порівняти з довіреною особою в базі даних MPIякщо значення drfo рівне tax_id regexp (
^[0-9]{10}$
), полу містить tax_id, порівняти зpersons.tax_id
;якщо значення drfo рівне номеру national_id regexp (
^[0-9]{9}$
), поле містить номер national_id, порівнятиdocument.number
з типом = 'NATIONAL_ID'якщо значення drfo містить хоча б одну літеру, виконати зворотню транслітерацію поля, використовуючи існуючий алгоритм (описаний тут), тоді перевірити, що значення рівне номеру паспорту regexp (
^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$
), в разі рівності, поле містить номер паспорту, порівнятиdocuments.number
з типом 'PASSPORT'в разі помилки - повернути 409 ('Unable to authenticate signer.')
Перевірити признак patient_signed
Запит на персону має бути підписаний тільки після того, як персона переглянула друковану форму.
Після того, як персона переглянула друковану форму, для поля patient_signed
має бути встановлено значення true та передане в $.signed_content
.
Перевірити, що поле
patient_signed
міститься в декодованому запиті на персонув разі помилки - повернути 422 ('required property patient_signed was not present')
Перевірити, що
patient_signed
= true в декодованому запиті на персонув разі помилки - повернути 422 ('value is not allowed in enum')
Перевірити завантажені документи
Отримати перелік типів документів, що мають бути завантажені до сховища даних в полі documents
для запиту на персону.
якщо перелік пустий - пропустити перевірки
якщо перелік не пустий - перевірити, що документи були завантажені, використовуючи Media Content Storage
в разі помилки - повернути 409 ('Documents <<document_types_to_upload>> is not uploaded') with types of documents that must be uploaded to media content storage
Сервісна логіка
Зберегти підписаний запит на персону до сховища даних
Після того, як запит на персону було успішно підписано, зберегти підписаний запит на персону до сховища даних.
Отримати назву бакету з конфігураційного параметру MEDIA_STORAGE_PERSON_REQUEST_BUCKET, зберегти запит на персону до папки /person_requests/person_request_id
з назвою файлу signed_content
.
Оновити запит на персону
Оновити запит на персону, встановити значення:
status = SIGNED
updated_by = user_id з токену
updated_at = now()
patient_signed = true
person_id = person_id з токену
Оновити запити на декларацію зі статусом
Знайти активні запити на декларацію в таблиці IL.declaration_requests з наступними пошуковими параметрами:
mpi_id = person_id з токену
status = NEW або APRROVED
Якщо знайдено - відмінити запити на декларацію, встановити значення:
status = CANCELLED
status_reason = request_cancelled
updated_at = now()
updated_by = user_id з токену
Оновити персону
Оновити існуючу персону (з person_id з токену) в базі даних MPI.
Встановити значення у наступних таблицях для запиту на персону:
таблиця
persons
таблиця
person_phones
таблиця
person_addresses
таблиця
person_documents
Вказати персону для верифікації
Оновити існуючий запис в таблиці person_verifications
для персони у відповідност і до логічного блоку нижче. Також, встановити:
updated_at = now()
updated_by = user uuid
Ручна верифікація NHS
Вказати персону для ручної верифікації НСЗУ у відповідності до наступної логіки: Sign person request | Manual NHS verification
Верифікація по реєстру DRFO
Вказати персону для верифікації по реєстру DRFO у відповідності до наступної логіки: Sign person request | DRFO registry verification
Верифікація по реєстру актів смерті DRACS
Вказати персону для верифікації по реєстру актів смерті DRACS у відповідності до наступної логіки: Sign person request | DRACS death acts registry verification
Розрахувати комулятивний статус верифікації
Розрахувати комулятивний статус верифікації персони у відповідності до наступної логіки: Sign person request | Calculate cumulative verification status
Оновити взаємозв'язок між довіреною персоною та оновленою персоною
В разі, якщо хоча б один тип документу по вказаній персоні вказано в конфігураційному параметрі PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES - деактивувати всі існуючі взаємозв'язки з довіреною особою для персони:
Деактивувати всі записи в таблиці IL.confidant_person_relationship_requests, де person_id =
person.id
та статус = NEW, встановити значення:status = CANCELLED
updated_at = now()
updated_by = user_id (з токену)
Деактивувати всі записи в таблиці MPI.confidant_person_relationship, де person_id =
person.id
та is_active = true, встановити значення:is_active = false
updated_at = now()
updated_by = user_id (з токену)
Для всіх взаємозв'язків з попереднього кроку - деактивувати методи автентифікації в таблиці MPI | person_authentication_methods з типом = THIRD_PERSON та значення =
confidant_person_relationships.confidant_person_id
, встановити значення:is_active = false
ended_at = now()
updated_at = now()
updated_by = user_id (з токену)
Відобразити відповідь
Відобразити відповідь у відповідності до специфікації.
ЕСОЗ - публічна документація