Мета

Надати можливість адміністратору НСЗУ/Дата стюарту (співробітник НСЗУ з відповідними скоупи) зберегти оновлення персональних даних персон, на основі отриманих від персон офіційних звернень в НСЗУ, які по факту є легальною авторизацією на зміну персональних даних пацієнтів.

Схема

Дизайн

Editing

Почати редагування, гляхом вибору 'Редагування'

Ввести зміни

Порівняння змін перед підписом

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

index.graphql

"Creates a person_request record with the status SIGNED (in il.person_request) with following update of a person record (in mpi.persons)."
  createPersonRequest(
    input: CreatePersonRequestInput!
  ): CreatePersonRequestPayload

persons.graphql

"""
Input for `createPersonRequest` mutation.
User must have a scope **person_request:write_nhs**
"""
input CreatePersonRequestInput {
  "Signed data to create Person_Request for update of a person record in mpi.persons"
  signedContent: SignedContent!
  "This parameters is MPI.person.(id of edited person).inserted_at, saved in FE at the beginning of editing process and should be transferred to BE for validation of parallel editing"
  updatedAtForValidation: DateTime!
}

"""
Return type for `createPersonRequest` mutation.
"""
type CreatePersonRequestPayload {
  "Updated data of a Person - from mpi.persons"
  person: Person!
}

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

Процес ініціюється співробітником НСЗУ (тільки через адміністративну панель НСЗУ) з відповідними скоупами та ініціює передачу (за допомогою graphQL мутації) підписного контенту (signed_content). Це включає JSON з персональними даними, де id існуючої персони та no ключів та параметрів методів аутентифікації.

Він має схожість до частини оновлення (update part) в поцесі IL.Update-person-request (w/o declaration) , але є основні відмінності:

Запис по Person_request створюється на BE в статусі SIGNED на основі signed_content(який підписано цифровим підписом) з FE. Без проміжних записів до DB з такими статусами, як NEW, APPROVED.
Під час процесу оновлення персональних даних персони до таблиці MPI.person відсутня необхідність в підтвердженні від персони в форматі ONLINE/OFFLINE.
Є два нових параметри для контролю об'єму змін та уникнення ризику надлишкової автоматичної дедублікації:
1. PERSON_ONLINE_DEDUPLICATION_UPDATE_SCORE_NHS_ADMIN
2. PERSON_ONLINE_DEDUPLICATION_MATCH_SCORE_NHS_ADMIN
  Дані параметри можуть бути включені\виключені за допомогою:
  1. PERSON_ONLINE_DEDUPLICATION_UPDATE_SCORE_NHS_ACTIVE = true
  2. PERSON_ONLINE_DEDUPLICATION_MATCH_SCORE_NHS_ACTIVE = true
Наявні наступні обов'язкові поля в запиті:
1. ```
  nhs_request_number
  nhs_request_comment 
```
Та є наступні відмінності в полях, значеннях та перевірках:
1. $.patient_signed та $.process_disclosure_data_consent не повинні бути вказані в запиті та тому значення null має бути встановлено в IL.person_requests. Та нарешті, в таблиці MPI.persons дані значення повинні бути перезаписані.
2. друкована форма не обов'язкова
3. IL.person_requests.(new record).channel = 'NHS'
Один додатковий параметр переданий від FE до BEupdatedAtForValidation
second_name та unzr мають бути встановлені в null. no_tax_id та tax_id можуть бути передані в повідомленні як null, якщо вони обидва встановлені в null.

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

Скоупи та ролі

Назва скоупу

Ролі

Опис

Новий

person_request:write_nhs

ADMIN
NHS ADMIN VERIFIER

Скоуп для створеня записуperson_request з послідуючим оновлення запису person. Без погодження персони по online/offline . Оскільки паперовий запит до НСЗУ - це юридична авторизація на зміни персональних даних персони.

Пов'язані статті

#

Шлях

Посилання та стаття

1

E-Health > Persons > Ідентифіковані персони > Person Requests Technical Requirements

IL.Create/Update person request (w/o declaration)

Create/Update person request

2

Public. Medical Service Provider Integration Layer > Person Requests

https://uaehealthapi.docs.apiary.io/#reference/public.-medical-service-provider-integration-layer/person-requests

Авторизація

Перевірити валідність токену доступу
1. Повернути помилку 401 в разі неуспішної валідації
Перевірити скоупи користувача person_request:write_nhs
1. Повернути помилку 403 в разі невалідних скоупів

Цифровий підпис

Декодувати контент: що зашивровано в цифровому підписі.
Використати цифровий підпис запиту. Метод перевіряє цифровий підпис та повертає результат.
Див сервіс specification

Перевірити ДРФО

Перевірити, що DRFO в деталях сертифікату присутній в запиті
Перевірити, що DRFO в деталях сертифікату відповідає DRFO для Party
1. Отримати party.tax_id використовуючи employee_id в даних персони
2. Порівняти DRFO в сертифікаті з party.tax_id
  1. Змінити DRFO та TAX_ID на великі літери
  2. Порівняти DRFO та TAX_ID на літери кирилиці
  3. Змінити DRFO на кирилицю та перевірити на коректність
3. В разі неуспішних валідацій - віддати помилку 422

Співвідношення латиниці та кирилиці

%{"A" => "А", "B" => "В", "C" => "С", "E" => "Е", "H" => "Н", "I" => "І", "K" => "К", "M" => "М", "O" => "О", "P" => "Р", "T" => "Т", "X" => "Х"}

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

Отримати глобальні параметри

Для подальших перевірок, викликати Global parameters для отримання:

no_self_auth_age

cURL приклад

curl -X GET \
  {:host}/api/global_parameters

	Валідації
1	Перевірка на одночасні корегування даних (нове) Якщо дані персони не змінювались іншими користувачами (MSP, NHS) в системі НСЗУ. Шляхом попереднього збереження `updateAt` (збережено після початкового запиту персональних даних під час початку процесу редагування) та перевірити в момент збереження даних: `Якщо MPI.person.(id = $.id).update_At = $.updatedAtForValidation то Ok` в іншому випадку повернути помилку 422, 'Person's data were changed while you were editing. Please repeat your steps for update'
2	Перевірити статус персони в базі даних та інструментах дедублікації Якщо `person.id` в запиті, то `якщо $.person.id в UUID та UUID_version($.person.id is UUID) = 4 то ok` в разі помилки, повернути помилку 422, “person.id is not UUID type or UUID version is not appropriate“ знайти персону по person.id в MPI в разі помилки повернути код 404, "not found" `Якщо MPI.persons.($.id).status = “active” то ok` в разі помилки повернути код 422 - та повідомлення "The Person is not active, therefore any updates of personal data are prohibited” Скор рівня оновлень Перевірити декодований підписний контент шляхом використання інструментів дедублікації в частині двої перевірок . I.e. Перевірка дедублікації 1 перевірити, що рівень змін є “so high” що потрібно призупинити (відмовити) в збереженні змін. `якщо calculated_score (current data, updates_of_Person) > PERSON_ONLINE_DEDUPLICATION_UPDATE_SCORE_NHS_ADMIN` `то` Перевірка 1 пройдена, пройти інші перевірки в іншому випадку повернути код 409, "Level of conducted changes is higher than permitted. Updates can't be saved. Please check whether you have selected appropriate Person for changes. Calculated score: `<calculated_score>`. Permitted score: `PERSON_ONLINE_DEDUPLICATION_UPDATE_SCORE_NHS_ADMIN`) " Перевірка дедублікації 2 - на відсутність такої персони, яка дуже схожа на поточну з врахування корегувань `якщо calculated_score (updates_of_Person, other_similar_Persons) < PERSON_ONLINE_DEDUPLICATION_MATCH_SCORE_NHS_ADMIN` `то` Перевірка 2 пройдена, пройти ініші перевірки в іншому випадку повернути код 409, "We have found Person(s) with high similarity in DB. Calculated score is equal or greater than permitted `PERSON_ONLINE_DEDUPLICATION_MATCH_SCORE_NHS_ADMIN`. Please check whether you have selected appropriate Person for changes and investigate possible duplicates of the Person." Перевірки дедублікації 1 та 2 можуть бути вимкнені шляхом встановлення кожного окремо наступні параметри `PERSON_ONLINE_DEDUPLICATION_UPDATE_SCORE_NHS_ADMIN_OFF` = `true` `PERSON_ONLINE_DEDUPLICATION_MATCH_SCORE_NHS_ADMIN_OFF` = `true`
3	Перевірити “patient_signed” признак. Дане поле не повинно передаватися. І тому BE не повинен здійснювати пошук його в DB
4	Перевірити “process_disclosure_data_consent” признак. Дане поле не повинно передаватися. І тому BE не повинен здійснювати пошук його в DB
5	Перевірити довірену особу `Якщо для персони age < prm.global_parameters.no_self_auth_age то` `перевірити на наявність confidant_person` в разі помилки повернути код 422 - та повідомлення "Confidant person is mandatory for children" Перевірити вік довіреної персони >= prm.global_parameters.no_self_auth_age: в разі помилки повернути код 422, " Third person must be adult” перевірити наявність секретного слова: in case of error return 422
6	Перевірити "tax_id" tax_id відповідає шаблону валідації - `^[0-9]{10}$` якщо не відповідає, повернути помилку 422 "string does not match pattern ..." співробітник НСЗУ може оновити `birth_date`, але `(If VALIDATE_TAX_ID_WITH_BIRTH_DATE_GENDER_AND_CHECK_SUM is false then ok` `If (GetBirthDateFromTaxId($.tax_id) != $.birth_date) then` в разі помилки повернути код 422 “Person's tax ID is not valid. “) `else ok` Співробітник НСЗУ може оновити `tax_id`: з `null` на `tax_id2`, на наявність персони з таким же `tax_id2` `if tax_check_cnt_1 = 0 then ok` Для отримання `tax_check_cnt_1`: `select count() tax_check_cnt_1 select from persons where tax_id = $.person.tax_id and status = 'active' and id <> $.person.id and is_active = true` в разі помилки повернути код 422 “There is another active person in DB with the same Tax_id. Updates to Personal data were not saved. “ Та з `tax_id1` на `tax_id2`, на наявність персони з таким же `tax_id2` `if tax_check_cnt_1 = 0 then ok` Для отримання`tax_check_cnt_1`: `select count() tax_check_cnt_1 select from persons where tax_id = $.person.tax_id and is_active = 'active' and id <> $.person.id` в разі помилки повернути код 422 “There is another active person in DB with the same Tax_id. Updates to Personal data were not saved. “ з `tax_id1` на `null` з `null` на `null`
7	Перевірити признак "no_tax_id" `"no_tax_id"` може бути `null` в повідомленні, якщо `tax_id` є також `null`. `If "no_tax_id"= true, tax_id` повинен бути пустим в разі помилки повернути код 422 `If "no_tax_id"=false and age>14, tax_id` повинен бути наявним в разі помилки повернути код 422
8	Перевірити документи персони issued_at, issued_by обов'язкові для документів Перевірити дати issued_at <= now() та issued_at => birth_date в разі `issued_at > now()` відобразити помилку 422, "Document issued date should be in the past" в разі `issued_at < person.birth_date` відобразити помилку 422, "Document issued date should greater than person.birth_date " expiration_date > now() в разі помилки відобразити 422, "Document expiration_date should be in the future" expiration_date обов'язкові для document_type NATIONAL_ID COMPLEMENTARY_PROTECTION_CERTIFICATE PERMANENT_RESIDENCE_PERMIT REFUGEE_CERTIFICATE TEMPORARY_CERTIFICATE TEMPORARY_PASSPORT в разі помилки повернути 422, "expiration_date is mandatory for document_type $.documents.type" Перевірити documents_type.number у відповідності до схеми json PASSPORT - `^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$` NATIONAL_ID - `^[0-9]{9}$` BIRTH_CERTIFICATE - `^((?![ЫЪЭЁыъэё@%&$^#`~:,.\|}{?!])[A-ZА-ЯҐЇІЄ0-9№\\/()-]){2,25}$` COMPLEMENTARY_PROTECTION_CERTIFICATE - `^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$` REFUGEE_CERTIFICATE - `^((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{6}$` TEMPORARY_CERTIFICATE - `^(((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{4,6}\|[0-9]{9}\|((?![ЫЪЭЁ])([А-ЯҐЇІЄ])){2}[0-9]{5}\\/[0-9]{5})$` TEMPORARY_PASSPORT - `^((?![ЫЪЭЁыъэё@%&$^#`~:,.\|}{?!])[A-ZА-ЯҐЇІЄ0-9№\\/()-]){2,25}$` 'unzr' може приймати значення `null` в повідомленні. якщо `unzr` існує і не є null і відповідає "^[0-9]{8}-[0-9]{5}$" перевірити їх 8 символів = birth_date в разі помилки повернути 422, повідомлення "Birthdate or unzr is not correct" якщо documents.type=NATIONAL_ID перевірити, що unzr наявний в запиті, в разі помилки повернути 422, повідомлення "unzr is mandatory for document type NATIONAL_ID" Документу numbersmaxLength < 25
9	Перевірити поля запиту NHS `nhs_request_number`, `nhs_request_comment` обов'язкові Перевірити їх у відповідності до схеми json якщо не відповідає, повернути помилку 422 “ `required property %{property} was not present`"

Схема валідації JSON

Перелік додаткових вимог для панелі адміністрування НСЗУ

Основною приймається дана схема JSON Schema validator (https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/589266986#Update-person-request ). Окрім:

“patient_signed" та "process_disclosure_data_consent" не обов'язкові і не мають бути наявними.
дозволити значення null в полі second_name об'єкту персон.
1. "second_name": { "type": [ "string", "null" ] }
дозволити значення null в полі unzr об'єкту персон
1. "unzr": { "type": [ "string", "null" ], "pattern": "^[0-9]{8}-[0-9]{5}$" }
дозволити в повідомлення обидва tax_id, no_tax_id зі значенням null якщо вони обидва приймають значення null
ключ updatedAtForValidation та ключ групування nhs_request_number, nhs_request_comment перевіряються згідно наступної схеми валідації:

перевірка nhsComment та updatedAtForValidation

  "nhs_request_number": {
  "type": "string",
  "description": "NHS internal Docflow's number of Person's official request to NHS",
  "maxLength": 50
  },
  "nhs_request_comment":{
  "type": "string",
  "description": "Title of an official Person's request to NHS or a description of that official request to NHS"},
  "maxLength": 3000
  }

    "updatedAtForValidation": {
      "type": "string",
      "format": "date-time"
    }

Виконання

Оновлення пошуку person_requests в IL.person_requests

Пошук запиту персони в IL.person_requests для попередження випадків одночасного оновлення даних:

WHERE IL.person_requests.person_id = :($.person.id)
  AND IL.person_requests.status IN ('NEW', 'APPROVED')

Відмінити person_requests records в IL.person_requests

Змінити статус всіх знайдених запитів персони:

SET   IL.person_requests.status = 'CANCELED'
WHERE IL.person_requests.id IN (:LIST of Search results)

Створити новий запис в IL.person_requests

Додати [new record] до IL.person_requests:
1. Встановити status = 'SIGNED'.
2. Встановити id персони, person_id = $.person.id
3. Встановити inserted_at= now() (отримати поточні дату та час)
4. Встановити inserted_by - user_id (отримати користувача з токену)
5. Встановити channel, IL.person_request.(newrecord).channel = 'NHS'
6. Встановити printout_form = null

Зберегти `signed_content` у відповідному бакеті Person_request

Оновити персону в MPI.persons

Оновити дані персони в MPI.persons.(id = $.person.id)з вказаними новими даними $ (включно два $.nhsRequestNumber та$.nhsRequestComment).
Встановити updated_at - now() (Отримати поточну дату та час)
Встановити updated_by - user_id (Отримати користувача з токену)
Створити відповідний запис на основі вказаних нових даних $ (включно два $.nhsRequestNumber та$.nhsRequestComment) в:
1. MPI.person_documents
2. MPI.person_phones
3. MPI.person_addresses

Направити персону на верифікацію

Створити або оновити існуючий запис в таблиці person_verifications для персони у відповідності до логікив секції нижче. Також, встановити:

updated_at = now()
updated_by = user uuid
inserted_at = now() (для нових записів)
inserted_by = user uuid (для нових записів)

Розрахувати кумулятивний статус верифікації

Розрахувати кумулятивний статус верифікації у відповідності до логіки https://e-health-ua.atlassian.net/wiki/spaces/DRACS/pages/17249206422/IL.Sign+person+request+modified#Calculate-cumulative-verification-status

(GraphQL) Update Person_UA

Мета

Схема

Дизайн

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

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

Скоупи та ролі

Пов'язані статті

Авторизація

Цифровий підпис

Перевірити ДРФО

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

Отримати глобальні параметри

cURL приклад

Перевірка на одночасні корегування даних (нове)

Перевірити статус персони в базі даних та інструментах дедублікації

Перевірити “patient_signed” признак.

Перевірити “process_disclosure_data_consent” признак.

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

Перевірити "tax_id"

Перевірити признак "no_tax_id"

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

Перевірити поля запиту NHS