Table of Contents |
---|
Purpose
This WS give gives the opportunity to create an unidentified person in eHealth. It means that person can be created w/o any information about it.
Specification
Page Properties | ||
---|---|---|
| ||
...
|
Logic
Only authenticated and authorized SPECIALIST, ASSISTANT, RECEPTIONIST employees can register prepersons.
Prepersons can be registered in OUTPATIENT and EMERGENCY legal entities.
Prepersons shoul be registered only with external_id as a required field. Other are optional
Preperson registers as separate record in MPI.prepersons table. On create ID of preperson sholdn’t match with ID of existent person.
Service should return preperson_id
...
.
Preperson has been created without using digital sign.
Request structure
See on Apiary
Example:
Expand | ||
---|---|---|
| ||
|
Dictionaries
GENDER
PHONE_TYPE
Authorize
Verify the validity of access token
...
return 401 in case validation fails
Check user scopes in order to perform this action (scope = 'preperson:write')
...
return 403 in case invalid scope(s)
If BLOCK_UNVERIFIED_PARTY_USERS is true, then check party's data match following condition: verification_status != NOT_VERIFIED or (verification_status = NOT_VERIFIED and updated_at <= current_date - UNVERIFIED_PARTY_PERIOD_DAYS_ALLOWED):
in case not match - return 403 ("Access denied. Party is not verified")
Headers
Content-Type:application/json
Authorization:Bearer {{access_token}}
api-key:{{secret}}
Request data validation
Validate legal entity
Check that legal entity is active (status = ACTIVE) and belongs to the user
Extract client_id from token
Check legal entity status (status = ACTIVE)
In case of error - return 409 (Legal entity must be ACTIVE)
Check legal entity has at least one healthcare service with status = ACTIVE and providing_condition = INPATIENT and speciality_type in PREPERSON_HEALTHCARE_SERVICES_SPECIALITY_TYPES variable (value should exist in SPECIALITY_TYPE dict)
if no such healthcare services - return 409 (Legal entity does not have appropriate healthcare services)
Validate request
Validate request using schema (TBD)
Validate birth_date - must be <= today()
else error 422 "Birth date can't be in the future"
Validate external_id
Check external_id is not empty.
In case of error - return 422 (external_id should not be empty)
Validate according to regexp -
...
^[0-9]{8,10}\.[0-9]{8,10}\.[0-9]{1,10}$
Processing
Generate preperson_id
Generate preperson_id (will be returned in response). Ensure there is no such person_id in MPI.persons
Generate patient_id to save it in patients collection (separate job).
Save object to DB
Insert preperson to MPI
prepersons table
Parameter | Source | Description |
---|---|---|
id | string | Autogenerated. |
first_name | Request: first_name | |
second_name | Request: second_name | |
last_name | Request: last_name | |
gender | Request: gender | Gender, required. The values correspond to GENDER dictionary |
birth_date | Request: birth_date | |
emergency_contact | Request: emergency_contact | |
death_date | date | By default is null on create |
note | Request: note | |
status | string | Status, required. By default is “active” |
external_id | Request: external_id | Identifier from external system. Required |
is_active | bool | Technical flag. By default is true. |
inserted_by | uuid | Extract user from token |
inserted_at | timestamp | Get current date-time |
updated_by | uuid | Extract user from token |
updated_at | timestamp | Get current date-time |
Response structure
See on Apiary
Example:
Expand | ||
---|---|---|
| ||
|
HTTP status codes
Page Properties | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|