ЕСОЗ - публічна документація
RC_Rules to validate patient data (DRACS 2.0)
- Anna Popelysheva (SoE eHealth)
- 1 Purpose
- 2 Regular person
- 2.1 Validations
- 2.1.1 Validate schema
- 2.1.2 Validate person
- 2.1.3 Validate person documents
- 2.1.4 Validate person addresses
- 2.1.5 Validate person authentication methods
- 2.1 Validations
- 3 Person with confidant
- 3.1 Validations
- 3.1.1 Validate schema
- 3.1.2 Validate person
- 3.1.3 Validate person documents
- 3.1.4 Validate person addresses
- 3.1.5 Validate сonfidant person
- 3.1.6 Validate person authentication methods
- 3.1 Validations
Purpose
This page describes validation rules for person data (both regular person and person than have confidant person) as part of sign-up processes through person information system (PIS).
Regular person
Key points for regular person dataset:
Schema does not allow to submit “confidant_person” block
There is a need to check if persons age is greater then no_self_registration_age chart parameter
Person authentication methods must contain only records with
type = 'OTP'
This validation rules set is currently used by following WS:
Validations
Validate schema
Validate person data according to JSON Schema:
in case field value does not match the schema - return 422 with field-specific message
in case additional fields exist in request - return 422 ('schema does not allow additional properties')
in case required parameter does not exist in request - return 422 ('required property %{property} was not present')
in case required amount of parameters does not exist in request - return 422 ('expected a minimum of %{min} items but got %{actual}')
Validate person
Validate
tax_idaccording to existing validations, described here: Create/Update person request | Validate "tax_id"Validate
no_tax_idaccording to existing validations, described here: Create/Update person request | Check "no_tax_id" flagCheck persons age is greater then no_self_registration_age chart parameter
in case of error - return 422 ('Incorrect person age for such an action')
Validate person documents
Check submitted person document types exist in PIS_PERSON_REGISTRATION_DOCUMENT_TYPES config parameter that contains values from DOCUMENT_TYPE dictionary
in case of error - return 422 ('Submitted document type is not allowed')
Check documents that prove persons legal capacity
In case if persons age is greater then no_self_registration_age global parameter, but less then person_full_legal_capacity_age global parameter:
Check if at least one of submitted person document types exist in PIS_PERSON_REGISTRATION_DOCUMENT_TYPES config parameter that contains values from DOCUMENT_TYPE dictionary
in case of error - return 422 ('Document that proves personal data must be submitted')
Check if at least one of submitted person document types exist in PIS_PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter that contains values from DOCUMENT_TYPE dictionary
in case of error - return 422 ('Document that proves legal capacity must be submitted')
If at least one document type from PERSON_LEGAL_CAPACITY_DOCUMENT_TYPES config parameter is submitted, check that only one legal capacity document type is submitted
in case of error - return 422 ('Only one legal capacity document must be submitted')
Else check that any of submitted person document types exist in PIS_PERSON_REGISTRATION_DOCUMENT_TYPES config parameter
in case of error - return 422 ('<Document type> can not be submitted for this person')
Validate person documents according to exiting validations, described here: Create/Update person request | Validate person documents
Validate person addresses
Check that one address record with
type = 'RESIDENCE'is submittedin case of error - return 422 ('one and only one residence address is required')
Validate person authentication methods
Check that submitted authentication_methods contains only records with
type = 'OTP'in case of error - return 422 ('Only OTP authentication method can be created for person')
Validate phone number limit according to existing validation, described here: Create/Update person request | Validate phone number limit
Person with confidant
There are few differences between validation of reqular person and validation of person with confidant:
Schema allowes to submit “confidant_person” block
User can set only one confidant person and only one authentication method
There is no need to check if persons age is greater then no_self_registration_age chart parameter
To validate submitted document types another config parameter is used (PIS_PERSON_WITH_CONFIDANT_REGISTRATION_DOCUMENT_TYPES)
Person authentication methods must contain only records with
type = 'THIRD_PERSON'Confidant person must be validated
This validation rules set is currently used by following WS:
https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599398851
https://e-health-ua.atlassian.net/wiki/spaces/PCAB/pages/17599399326
Validations
Validate schema
Validate person data according to JSON Schema:
in case field value does not match the schema - return 422 with field-specific message
in case additional fields exist in request - return 422 ('schema does not allow additional properties')
in case required parameter does not exist in request - return 422 ('required property %{property} was not present')
in case required amount of parameters does not exist in request - return 422 ('expected a minimum of %{min} items but got %{actual}')
Validate person
Validate
tax_idaccording to existing validations, described here: Create/Update person request | Validate "tax_id"Validate
no_tax_idaccording to existing validations, described here: Create/Update person request | Check "no_tax_id" flag
Validate person documents
Check submitted person document types exist in PIS_PERSON_WITH_CONFIDANT_REGISTRATION_DOCUMENT_TYPES config parameter that contains values from DOCUMENT_TYPE dictionary
in case of error - return 422 ('Submitted document type is not allowed')
Validate person documents according to exiting validations, described here: Create/Update person request | Validate person documents
Validate person addresses
Validate person addresses according to existing validation, described here: Create/Update person request | Validate person documents
Validate сonfidant person
Check if confidant_person.person_id is the same person who initiates patient registration (confidant_person.person_id = applicant person_id, obtained from digital signature)
in case of error - return 422 ('Person who initiates registration of patient must be submitted as confidant person')
Check if confidant_person.person_id exists in persons table (MPI DB)
in case of error - return 422 ('Confidant patient is not found')
Check if confidant person age >= no_self_registration_age chart parameter
in case of error - return 422 ('Incorrect person age for such an action')
Check if confidant person cumulative verification status is not in
NOT_ALLOWED_CONFIDANT_PERSON_VERIFICATION_STATUSESconfig parameterin case of error - return 422 ('Person with cumulative verification status <verification_status> can not be submitted as confidant')
Check if confidant person has authentication method with
type = OTPwhere ended_at is equal to or greater than today`s datein case of error - return 422 ('Confidant person must have active authentication method with type "OTP" where ended_at is equal to or greater than current date')
If $.documents_relationship.[x].type contains BIRTH_CERTIFICATE or BIRTH_CERTIFICATE_FOREIGN values, check that persons age < person_full_legal_capacity_age global parameter
in case of error - return 422 ('Invalid relationship document type for person in such age')
Validate person authentication methods
Check that submitted authentication_methods contains only one record and this record has
type = 'THIRD_PERSON'in case of error - return 422 ('Only THIRD_PERSON authentication method can be created for person')
Check if THIRD_PERSON is the same person who initiates patient registration and submitted as confidant (authentication_methods.value = applicant person_id, obtained from digital signature)
in case of error - return 422 ('person.authentication_methods.value must be equal to person.confidant_person.person_id')
ЕСОЗ - публічна документація